February 4, 2011 at 17:18Drupal Caching
Recently, I was faced with the fact that my site on Drupal began to slow down. Moreover, the site is not particularly visited. Ultimately, the problem was resolved by switching to another hosting (shared hosting from Rucentr could not stand it in any way), but I don’t want to talk about this, but about the problems of Drupal acceleration by caching that I encountered.
So, what acceleration tools do Drupal have?
- Built-in caching at admin / settings / performance. Caching has two modes, normal and aggressive. Aggressive is not recommended for use as it conflicts with many modules. Normal, in principle, has no serious consequences. Designed only for anonymous users, and does not cache pages that run CAPTCHA.
- boost module. Like built-in caching, this module is designed for anonymous users. It stores its data on disk. If you enable boost, it is recommended that you disable normal caching. Boost prepares static pages in advance for anonymous users, so with anonymous boost enabled, the site “flies”. Unfortunately, boost has the following disadvantages. For adequate updating of pages on the site, the cache should be cleaned regularly (boost tries to clear it in parts when changes occur, but this does not always work fine). Therefore, the cache of the entire site must constantly be rebuilt. That already puts a load on the hosting, leading to the fact that the site “flies” for anonymous users, and for registered users it slows down even more. In addition, when rebuilding the cache, it can compress inserted images from external sources, leading to increased traffic on the site.
- Caching using nginx for anonymous users. It is well described here in a good article on Habré . I would add on my own this: do not forget to configure nginx so that it is he, and not Apache, who gives all sorts of pictures. This will save you a lot of RAM.
- authcache modulefor caching pages for registered users. Defines the set of roles for which caching is enabled. The page is cached if all user roles fall into this set. Actually, a cached page version is built for any subset of allowed roles. Therefore, if you enable this module, do fewer different roles. Also, do not enable it for anonymous users - boost will do this much better. Things like username, authcache caches as a template, replacing it with direct page output. Therefore, for registered users, it’s not going to be pure html, but some preparation. Which can be slow, because as we recall, the server is busy with us, because boost works all the time. It is best to store data using the cacherouter module, which in turn has options. Disk storage was the best fit for me.
- Optimization of javascript and css to load one file, not a lot. Enabled on the embedded caching page. Do not forget to clear the cache when updating the modules - otherwise css may not load at all for some users! Actually, in all the above methods, it is best to clear the cache after changes on the site.
- Using data uri to insert pictures directly in css. Implemented by the css_emimage module .
Here, in fact, in my opinion, the main methods of accelerating Drupal. And, of course, moving to a good hosting also drives. And I still summarize the problems:
- On weak hosting, caching will not save you. Because caching is also a constant load on the hosting.
- It is necessary to determine whose caching is more important to you, anonymous or registered. Perhaps both will work poorly at the same time
- you (the site administrator) do not fundamentally see how caching works under your account
- Do not forget to disable the entire cache when updating modules
- The included boost spends traffic
- And in general. Drupal is comfortable but heavy. I have to admit it.
So, what acceleration tools do Drupal have?
- Built-in caching at admin / settings / performance. Caching has two modes, normal and aggressive. Aggressive is not recommended for use as it conflicts with many modules. Normal, in principle, has no serious consequences. Designed only for anonymous users, and does not cache pages that run CAPTCHA.
- boost module. Like built-in caching, this module is designed for anonymous users. It stores its data on disk. If you enable boost, it is recommended that you disable normal caching. Boost prepares static pages in advance for anonymous users, so with anonymous boost enabled, the site “flies”. Unfortunately, boost has the following disadvantages. For adequate updating of pages on the site, the cache should be cleaned regularly (boost tries to clear it in parts when changes occur, but this does not always work fine). Therefore, the cache of the entire site must constantly be rebuilt. That already puts a load on the hosting, leading to the fact that the site “flies” for anonymous users, and for registered users it slows down even more. In addition, when rebuilding the cache, it can compress inserted images from external sources, leading to increased traffic on the site.
- Caching using nginx for anonymous users. It is well described here in a good article on Habré . I would add on my own this: do not forget to configure nginx so that it is he, and not Apache, who gives all sorts of pictures. This will save you a lot of RAM.
- authcache modulefor caching pages for registered users. Defines the set of roles for which caching is enabled. The page is cached if all user roles fall into this set. Actually, a cached page version is built for any subset of allowed roles. Therefore, if you enable this module, do fewer different roles. Also, do not enable it for anonymous users - boost will do this much better. Things like username, authcache caches as a template, replacing it with direct page output. Therefore, for registered users, it’s not going to be pure html, but some preparation. Which can be slow, because as we recall, the server is busy with us, because boost works all the time. It is best to store data using the cacherouter module, which in turn has options. Disk storage was the best fit for me.
- Optimization of javascript and css to load one file, not a lot. Enabled on the embedded caching page. Do not forget to clear the cache when updating the modules - otherwise css may not load at all for some users! Actually, in all the above methods, it is best to clear the cache after changes on the site.
- Using data uri to insert pictures directly in css. Implemented by the css_emimage module .
Here, in fact, in my opinion, the main methods of accelerating Drupal. And, of course, moving to a good hosting also drives. And I still summarize the problems:
- On weak hosting, caching will not save you. Because caching is also a constant load on the hosting.
- It is necessary to determine whose caching is more important to you, anonymous or registered. Perhaps both will work poorly at the same time
- you (the site administrator) do not fundamentally see how caching works under your account
- Do not forget to disable the entire cache when updating modules
- The included boost spends traffic
- And in general. Drupal is comfortable but heavy. I have to admit it.