Posted by Andy Inman on October 12, 2011 at 7:15pm
Using the APC module for D7 - I've done a very quick performance test, just to give an idea of what you might expect when serving cached pages (anonymous users) - I hope this is useful to someone:
Requests served per second measured using Apache ab
| Static HTML (what you might expect using Boost) | 1240 |
| APC cache, page_cache_without_database = TRUE | 650 |
| APC cache, page_cache_without_database = FALSE | 310 |
| Standard Drupal (database) cache, with working query-cache | 130 |
- ab command used: ab -H "Accept-Encoding: gzip" -n1600 -c8 http://localhost/node/20
- An almost minimal D7 installation but with multi-language (Internationalisation) activated
- Unloaded 2.2 GHz dual processor, 4GB RAM.
Note: It's important to include -H "Accept-Encoding: gzip" because otherwise results are slower due to the time taken for the server to uncompress gzip-compressed content before returning it.
To repeat, this was just a quick test and probably not very representative of real-world results, but hopefully better than nothing.
Here's what I put in my settings.php to quickly change configuration (change 1 to 0 where required):
if (1) {
$conf['cache_backends'] = array('sites/all/modules/apc/drupal_apc_cache.inc');
if (1) {
// Use APC by default (cache everything.)
$conf['cache_default_class'] = 'DrupalAPCCache';
if (1) {
// Page cache without database and module hooks (approx twice as fast.)
$conf['page_cache_invoke_hooks'] = FALSE;
$conf['page_cache_without_database'] = TRUE;
}
}
else {
// Use APC for "cache" and "bootstrap" only.
$conf['cache_class_cache'] = 'DrupalAPCCache';
$conf['cache_class_cache_bootstrap'] = 'DrupalAPCCache';
}
}
Comments
Very interesting! Thank you
Very interesting! Thank you for sharing.
Note: It's important to
huhwha? What would be gzipped on the server and requiring unzipping to be served?
The Boise Drupal Guy!
Assuming you've got page
Assuming you've got page compression being done by Drupal, i.e. Compress cached pages. turned on at admin/config/development/performance, then gzipped pages are stored in Drupal's page cache.
http://api.drupal.org/api/drupal/includes--common.inc/function/drupal_pa... ...
if (variable_get('page_compression', TRUE) && extension_loaded('zlib')) {$cache->data['body'] = gzencode($cache->data['body'], 9, FORCE_GZIP);
}
cache_set($cache->cid, $cache->data, 'cache_page', $cache->expire);
If the client accepts gzipped content (the normal case) then the already-compressed content is served without further processing, otherwise they have to be first uncompressed by Drupal, and that's what slows down the process slightly.
Agreed, it's a different situation if you that option is turned off - then either you have gzipping done by Apache (etc.) or not at all.
Currently part of the team at https://lastcallmedia.com in a senior Drupal specialist role.
Oh, okay, I follow. The
Oh, okay, I follow. The problem is that that Drupal setting is not used by anyone with any serious knowledge of server optimization, because it's of course faster to have the server daemon manage that sort of compression than to do it in Drupal/PHP. In fact, I'd lobby that that setting should be removed from Drupal seeing as how it seems to be abused so much by people who don't understand how it works.
At any rate, if you disabled that setting in Drupal but made sure that Gzip compression was enabled at the server daemon level, I bet you'd see slightly faster results hitting a single page over and over, but much faster results hitting several pages over and over again.
The Boise Drupal Guy!
In fact, I'd lobby that that
Sounds like a good idea, patch?
Patch?
How does the one attached to issue 1321918 look?
I can't seem to use the do issue linking ([#1321918] style) on gdo :( Am I missing something?
Fair comment, and please
Fair comment, and please remember my tests were only meant to indicate the benefits of using APC based page caching compared with standard Drupal database page-caching - neither of these would typically be used in a serious high performance environment.
Nonetheless, out of curiosity I disabled Drupal's internal compression and left it to Apache. Here are the results
Requests served per second
Conclusion - Letting Apache compress Drupal pages is slightly slower than the original figures (letting Drupal handle compression and caching compressed pages.) This figures becuase now: (1) Drupal's cache is storing data uncompressed, so increased transfer time when retrieving it from cache and (2) Apache is compressing the page on each request, so increased processing.
In summary, if you want to use Drupal's built-in page caching, it's probably better to let Drupal handle the compression too.
As before, these are all quick tests, and run on a development machine, not a tuned server, and may be unrepresentative of "real world" results.
Currently part of the team at https://lastcallmedia.com in a senior Drupal specialist role.
Apache is compressing the
Then it is not configured correctly. It should be caching the compressed data. When it goes to compress the next request, assuming the data is the same (it checks a hash), it should retrieve the cached compressed data instead of recompressing it.
The Boise Drupal Guy!
Benchmarks for this claim
http://drupal.org/node/101227#comment-3176382
Do you mean Apache should be
Do you mean Apache should be configured to caching the compressed data (mod_cache) ? Yes that would make it faster, I agree - we could go further and put Varnish in front, but this wasn't the objective of the original exercise! In summary, if you want a simple configuration using Drupal's build-in caching then caching in APC is considerably faster than default (database) - exactly what one would expect of course, I was just trying to get some approximate figures.
Just to clarify - I was talking about a scenario where, for whatever reason, we want to use Drupal's built-in page caching mechanism. In that scenario, by implication, we're not going to have additional front-end caching - why would we even want Drupal internal caching if that were the case?
Currently part of the team at https://lastcallmedia.com in a senior Drupal specialist role.
I'm not talking about Varnish
I'm not talking about Varnish or anything like that. I haven't actually used Apache at a high level in quite a while, since I'm more of a Lighty fan (probably gonna move to Nginx one of these days since Lighty seems to have stalled), so I'm speaking of what Lighty can do and assuming that Apache can do the same. But it's all very simple: The server gets a request from a browser that supports gzipping. If the file is processed through a script (such as Drupal), the server lets the script do its thing, then takes its output and makes a hash of it. It uses that hash to check the disk to see if a gzipped file for the same data hash exists in its cache directory (which in practice might even just be /tmp). If yes, then it simply serves that file instead of compressing the data it got back from the script. If no, it compresses the data, saves it to its cache directory, then sends it through the pipe. A later hit for the same page, assuming it results in the same content (and therefore the same hash), will be served the cached file. So if it's actually recompressing the data on every hit, then those cached files aren't being created somehow - maybe the directory selected to store those files in the configuration is not writable by the Apache process. At any rate, the caching is inherent in the process of compressing the pages itself - not something separate like Varnish.
And again, I'm only assuming Apache works the same way as Lighty does in this case, because it'd be pretty dumb/useless if it didn't.
The Boise Drupal Guy!
Apache Isn't That Smart
One would have to create some complex .htaccess rules to pull that off. We use nginx in front of varnish to gzip everything that comes out of our server stack as nginx is very fast and is smart.
http://httpd.apache.org/docs/current/mod/mod_cache.html
http://stackoverflow.com/questions/6386568/does-apache-cache-the-gzipped...
Complex .htaccess rules? No,
Complex .htaccess rules? No, that shouldn't be necessary. I really don't get it - are you all saying that Apache's gzip implementation doesn't cache by itself? That's just mind-numbingly stupid if true.
The Boise Drupal Guy!
Apache Rules vs Nginx
Hmm, with Apache; it is [experienced as] more complex to achieve the same results you can get with a few lines of 'Nginx' nginx.conf setup.
I have been on both paths, and the growing list 'function abilities' of what is possible with Nginx is very, very rewarding.
Nginx + Varnish is actually very good. I know that Lighty does something akin to this!
The nginx -> varnish front-end to gzip everything on a server stack is very fast! Beats all PHP methods,
and [additionally] offers recognition of gzip static assets (based on client end).
That is just the top of the sweet icing...within
--
Linux: Web Developer
Peter Bowey Computer Solutions
Australia: GMT+9:30
(¯`·..·[ Peter ]·..·´¯)
Blank page
When using APC and page_cache_without_database = TRUE I get a blank page once the page is cached :s
Anyone has a clue ? You can see the drupal site at my signature, however I'll disable it for the time being :|
JGO | http://www.hosted-power.com/en/vps