Drupal 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 solved by switching to another hosting (Routsentr's shared-hosting could not stand in any way), but I don’t want to tell you about it, but about the problems of accelerating Drupal through caching, which I encountered.
So what acceleration tools exist on Drupal?
')
- Built-in caching at admin / settings / performance. Caching has two modes, normal and aggressive. Aggressive is not recommended for use because it conflicts with many modules. Normal, in principle, does not have any serious consequences. It is designed only for anonymous users, and does not cache pages on which CAPTCHA works.
- Module boost . Like inline caching, this module is designed for anonymous users. He keeps his data on the disk. If you enable boost, it is recommended to turn off normal caching. Boost prepares static pages for anonymous users in advance, so the site “flies” with boost enabled for anonymous users. Unfortunately, boost has the following disadvantages. In order to adequately update the pages on the site, the cache should be cleaned regularly (boost tries, to clean it in parts when it changes, but this does not always work fine). Therefore, the cache of the entire site must constantly be rebuilt. What already gives the load to the hosting, leading to the fact that for anonymous websites the site “flies”, and for registered ones it slows down even more. In addition, when rebuilding the cache, it can inject embedded images from external sources, leading to an increase in traffic on the site. If you have a tariff with limited traffic, this can seriously upset you.
- Caching with nginx for anonymous users. Well described here in a good article on Habré . I would add this from myself: do not forget to configure nginx so that it is he who gave all the pictures, not Apache. This will save you a lot of RAM.
- Module authcache for caching pages for registered users. The set of roles for which caching is allowed is determined. A page is cached if all user roles fall into this set. Actually, for any subset of allowed roles, a version of the cached page is built. Therefore, if you enable this module, do fewer different roles. In addition, do not enable it for anonymous users - boost will do much better with this. Things like the username, authcache caches as a template, replacing it with direct page rendering. Therefore, for registered people, not pure html will go anyway, but some preparation. Which can be slow, because as we remember, our server is loaded, because boost works all the time. It is best to store data using the cacherouter module, which, in turn, has options. For me, disc storage was best suited.
- Optimize javascript and css to load a single file, not a lot. Enabled on inline caching page. Do not forget to clear the cache when updating modules - otherwise some users may not load css! Actually, in all the methods described above, it is best to clear the cache after changes on the site.
- Use data uri to insert images directly into css. Implemented by the css_emimage module.
That, in my opinion, is the main acceleration methods for Drupal. And, of course, moving to a good hosting rules too. And I still sum up the problems:
- On a weak hosting, caching will not save you. Because caching is also a constant load on hosting.
- It is necessary to determine whose caching is more important for you, anonymous or registered. Perhaps both will work poorly at the same time.
- You (the site administrator) do not see in your account how caching works
- We must not forget to disable the entire cache when updating modules
- Enabled boost traffic spending
- And generally speaking. Drupal is convenient, but heavyweight. I have to admit it.
So what acceleration tools exist on Drupal?
')
- Built-in caching at admin / settings / performance. Caching has two modes, normal and aggressive. Aggressive is not recommended for use because it conflicts with many modules. Normal, in principle, does not have any serious consequences. It is designed only for anonymous users, and does not cache pages on which CAPTCHA works.
- Module boost . Like inline caching, this module is designed for anonymous users. He keeps his data on the disk. If you enable boost, it is recommended to turn off normal caching. Boost prepares static pages for anonymous users in advance, so the site “flies” with boost enabled for anonymous users. Unfortunately, boost has the following disadvantages. In order to adequately update the pages on the site, the cache should be cleaned regularly (boost tries, to clean it in parts when it changes, but this does not always work fine). Therefore, the cache of the entire site must constantly be rebuilt. What already gives the load to the hosting, leading to the fact that for anonymous websites the site “flies”, and for registered ones it slows down even more. In addition, when rebuilding the cache, it can inject embedded images from external sources, leading to an increase in traffic on the site. If you have a tariff with limited traffic, this can seriously upset you.
- Caching with nginx for anonymous users. Well described here in a good article on Habré . I would add this from myself: do not forget to configure nginx so that it is he who gave all the pictures, not Apache. This will save you a lot of RAM.
- Module authcache for caching pages for registered users. The set of roles for which caching is allowed is determined. A page is cached if all user roles fall into this set. Actually, for any subset of allowed roles, a version of the cached page is built. Therefore, if you enable this module, do fewer different roles. In addition, do not enable it for anonymous users - boost will do much better with this. Things like the username, authcache caches as a template, replacing it with direct page rendering. Therefore, for registered people, not pure html will go anyway, but some preparation. Which can be slow, because as we remember, our server is loaded, because boost works all the time. It is best to store data using the cacherouter module, which, in turn, has options. For me, disc storage was best suited.
- Optimize javascript and css to load a single file, not a lot. Enabled on inline caching page. Do not forget to clear the cache when updating modules - otherwise some users may not load css! Actually, in all the methods described above, it is best to clear the cache after changes on the site.
- Use data uri to insert images directly into css. Implemented by the css_emimage module.
That, in my opinion, is the main acceleration methods for Drupal. And, of course, moving to a good hosting rules too. And I still sum up the problems:
- On a weak hosting, caching will not save you. Because caching is also a constant load on hosting.
- It is necessary to determine whose caching is more important for you, anonymous or registered. Perhaps both will work poorly at the same time.
- You (the site administrator) do not see in your account how caching works
- We must not forget to disable the entire cache when updating modules
- Enabled boost traffic spending
- And generally speaking. Drupal is convenient, but heavyweight. I have to admit it.
Source: https://habr.com/ru/post/113166/
All Articles