Another look at caching on Drupal
On Habré recently published an article entitled " Caching on Drupal ". I would like to add a few thoughts on the topic.
It's no secret that Drupal is hungry for resources, and caching is almost the first thing that comes to mind. I'll tell you how the general caching scheme is built on our site.
The first line of defense - we use the CDN (Content Delivery Network), in our case it is AKAMAI. AKAMAI is configured to cache everything. Pictures, CSS, JavaScript, answers to all GET requests, all of this is cached regardless of whether the user is anonymous or registered. The caching interval is 1 to 5 minutes for pages, 45 minutes for CSS and JavaScript, and an hour for other resources. This distribution can significantly reduce the load on the server.
Lyrical digression, for those who have no experience with CDN. Roughly speaking, all requests made to the site address first get to the CDN server, provided that the requested page exists in the CDN cache, the response is immediately sent to the requesting client from the CDN server. In the case when the resource is not yet cached in the CDN, or the caching time has expired, the CDN sends the request to our server, caches the response, and issues it to the user. In connection with this scheme, several problems arise, which however are quite easily solved.
Consider the problems in order. Problem number one is that in Drupal forms are supplied with form-tokens that Drupal uses for security purposes. The problem is solved in two ways, more secure (but increasing the load on the server), and more cached way. More secure is the AJAX request for the form itself, after the page has been displayed. The trick is that the CDN will return the page from its servers, but the AJAX request (it should be POST, the GETs are cached) to your server will generate a form, which we will then write in the right place using JS. The problem with the form-token is solved, because Drupal generates the form, and knows the correct value of its token. With this approach, we are guaranteed to have one request to our server. What, in principle, is not terrible, however, what to do when even this single request spoils life very much? The answer is to sacrifice security by simply removing the form-token to an ordinary unset'om. Voila, you can cache the form along with the page in the CDN. I would like to remind you that before you go the second way, weigh it well - and does this one request make it easier for you, or its absence? An example of a situation when this one request can play a cruel joke with you - your site was on the first page of yahoo.com with a direct link back to your material (20,000+ users simultaneously on your site for a few hours). By the way, this method can be used as needed, it is not at all necessary to make it a “permanent solution”.
')
Problem number two is related to the fact that caching comments is fraught with outraged users who will write letters with content like “I left comments here, where is he ?!”. Again, there are two solutions: AJAX request for fresh comments every time the page loads, or adding a cache buster parameter to the address where you return the user to the page with a comment (something like www.spin.com/articles/premiere-crystal-method- remix-daft-punks-tron? cb = cdninvalidate # comment-85251 ). The cb = cdninvalidate parameter is configured in the CDN, and lets the CDN know that the page caching time has expired. Thus, the user who just left a comment will update the cache for everyone else (because CDN will send a request to our servers, and cache the new version with a new comment).
The third problem is solved quite simply: a separate subdomain is allocated to the editorial staff, for example, edit.mysite.com, which is not cached by CDN.
CDN is not a panacea, and the next stage of caching about which I would like to say a few words is caching on their servers. The fact is that despite the fact that CDN significantly reduces the load on the server, with a large one-time influx of visitors, CDN alone is not enough. Memcache, APC is installed on our servers, native Drupal caching is enabled. Particular attention should be paid to block caching, this will make it even easier for your servers to work.
In addition to all the above, do not forget about simple things:
- Try to minimize the number of requests to your servers.
- Combine, where possible, images in CSS sprites.
- Think over the location of JavaScript in your code.
- Advertising, and other things that require a response from third-party servers, encapsulate in AJAX or iFrame.
- Do not feed PHP extra memory, use, for example php-fpm.
- Keep track of your MySQL logs, and optimize long executed queries.
- Consider the possibility of reading from two databases with high loads on the site.
That's probably all I wanted to add to the topic of caching and speed of Drupal today. Thank!
It's no secret that Drupal is hungry for resources, and caching is almost the first thing that comes to mind. I'll tell you how the general caching scheme is built on our site.
The first line of defense - we use the CDN (Content Delivery Network), in our case it is AKAMAI. AKAMAI is configured to cache everything. Pictures, CSS, JavaScript, answers to all GET requests, all of this is cached regardless of whether the user is anonymous or registered. The caching interval is 1 to 5 minutes for pages, 45 minutes for CSS and JavaScript, and an hour for other resources. This distribution can significantly reduce the load on the server.
Lyrical digression, for those who have no experience with CDN. Roughly speaking, all requests made to the site address first get to the CDN server, provided that the requested page exists in the CDN cache, the response is immediately sent to the requesting client from the CDN server. In the case when the resource is not yet cached in the CDN, or the caching time has expired, the CDN sends the request to our server, caches the response, and issues it to the user. In connection with this scheme, several problems arise, which however are quite easily solved.
- How to cache forms (for example, comment forms)?
- How to cache comments?
- How to edit content?
Consider the problems in order. Problem number one is that in Drupal forms are supplied with form-tokens that Drupal uses for security purposes. The problem is solved in two ways, more secure (but increasing the load on the server), and more cached way. More secure is the AJAX request for the form itself, after the page has been displayed. The trick is that the CDN will return the page from its servers, but the AJAX request (it should be POST, the GETs are cached) to your server will generate a form, which we will then write in the right place using JS. The problem with the form-token is solved, because Drupal generates the form, and knows the correct value of its token. With this approach, we are guaranteed to have one request to our server. What, in principle, is not terrible, however, what to do when even this single request spoils life very much? The answer is to sacrifice security by simply removing the form-token to an ordinary unset'om. Voila, you can cache the form along with the page in the CDN. I would like to remind you that before you go the second way, weigh it well - and does this one request make it easier for you, or its absence? An example of a situation when this one request can play a cruel joke with you - your site was on the first page of yahoo.com with a direct link back to your material (20,000+ users simultaneously on your site for a few hours). By the way, this method can be used as needed, it is not at all necessary to make it a “permanent solution”.
')
Problem number two is related to the fact that caching comments is fraught with outraged users who will write letters with content like “I left comments here, where is he ?!”. Again, there are two solutions: AJAX request for fresh comments every time the page loads, or adding a cache buster parameter to the address where you return the user to the page with a comment (something like www.spin.com/articles/premiere-crystal-method- remix-daft-punks-tron? cb = cdninvalidate # comment-85251 ). The cb = cdninvalidate parameter is configured in the CDN, and lets the CDN know that the page caching time has expired. Thus, the user who just left a comment will update the cache for everyone else (because CDN will send a request to our servers, and cache the new version with a new comment).
The third problem is solved quite simply: a separate subdomain is allocated to the editorial staff, for example, edit.mysite.com, which is not cached by CDN.
CDN is not a panacea, and the next stage of caching about which I would like to say a few words is caching on their servers. The fact is that despite the fact that CDN significantly reduces the load on the server, with a large one-time influx of visitors, CDN alone is not enough. Memcache, APC is installed on our servers, native Drupal caching is enabled. Particular attention should be paid to block caching, this will make it even easier for your servers to work.
In addition to all the above, do not forget about simple things:
- Try to minimize the number of requests to your servers.
- Combine, where possible, images in CSS sprites.
- Think over the location of JavaScript in your code.
- Advertising, and other things that require a response from third-party servers, encapsulate in AJAX or iFrame.
- Do not feed PHP extra memory, use, for example php-fpm.
- Keep track of your MySQL logs, and optimize long executed queries.
- Consider the possibility of reading from two databases with high loads on the site.
That's probably all I wanted to add to the topic of caching and speed of Drupal today. Thank!
Source: https://habr.com/ru/post/116384/
All Articles