Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.I ran two tests. First a jmeter test that Tag1 had previously set up for the 6.x-1.9 release for another client. I ran this against 6.x with both database and memcache backends, then upgraded that database to 7.x along with the jmeter test.
These tests show the 6.x version of memcache to be slightly slower than just using database caching. When reviewing this before, the only explanation I've had for this that made sense was that there is additional overhead from initiating the connection to memcache, which is not cancelled out by memcache itself (so even if set/get is a bit faster, a full page request can be slower), at least with the load tests.
With 7.x memcache comes in slightly faster in the jmeter tests, this is likely due to the considerably slower performance of the database cache backend in Drupal 7 compared to D6 (which is dbtng/PDO vs. mysqli extension).
Because the jmeter results were inconclusive, I also wrote a very quick script to call via drush, to just pit a lot of get / set / del calls against each backend. These show memcache to be consistently faster than the database in both versions, especially Drupal 7.
D6 Database:
HTTP return codes: 20x(42940) 30x(3419) 40x(12) 50x(0)
200: 42940
302: 3419
Pages per second: 73.02
D6 Memcache:
STAT total_connections 35073
STAT cmd_get 297996
STAT cmd_set 119882
STAT get_hits 177862
STAT get_misses 120134
STAT incr_hits 0
STAT bytes_read 141323177
STAT bytes_written 423816667
STAT evictions 62349
STAT total_items 119882
Hit rate: 59.6800%
Miss rate: 40.3100%
HTTP return codes: 20x(35052) 30x(3904) 40x(10) 50x(0)
200: 35052
302: 3904
Pages per second: 61.75
D7 database:
HTTP return codes: 20x(20521) 30x(1679) 40x(6) 50x(0)
200: 20521
302: 1679
Pages per second: 34.75
D7 memcache:
STAT total_connections 22224
STAT cmd_get 466405
STAT cmd_set 147008
STAT get_hits 319395
STAT get_misses 147010
STAT incr_hits 0
STAT bytes_read 164719612
STAT bytes_written 410788543
STAT evictions 78024
STAT total_items 147008
Hit rate: 68.4800%
Miss rate: 31.5100%
HTTP return codes: 20x(22206) 30x(1874) 40x(7) 50x(0)
200: 22206
302: 1874
Pages per second: 37.63
And the drush script:
This sets 100k items, then gets them, then clears them, uses timer_start()/timer_stop() before each operation loop.
| Backend | set | get | clear |
| Drupal 6 database | 43471ms | 22124ms | 15894ms |
| Drupal 6 memcache | 16267ms | 15090.63 | 7831ms |
| Drupal 7 database | 102502ms | 29210ms | 32827ms |
| Drupal 7 memcache | 14611ms | 13731.76 ms | 10919ms |
So for memcache 7, everything excepting clearing individual items is a bit faster than it was in Drupal 6, not a lot in it though. Re-running these I'm seeing up to 10% variation in the results but not more than that, and considering the quite high variation between each backend that seems OK for margin of error.
The big difference though is the considerably slower performance of the Drupal 7 database cache compared to everything else.
So results so far:
- in the jmeter load tests, memcache 7.x-1.x is performing equivalent or faster to the Drupal 7 database cache. (but Drupal 7 overall much slower then D6).
- in the php script benchmark, memcache 7.x-1.x is performing equivalent (with some variations) to memcache 6.x-1.x.
- memcache 7.x-1.x is considerably faster than the 7.x database cache, about six times as fast for inserts and more than twice as fast for get.
Possible todos:
- profile memcache 7.x-1.x cache clears vs. 6.x-1.x to see if it's possible to reproduce/diagnose the 20%-ish performance degradation (possibly after running the bench script with more iterations).
- profile the Drupal 6 load test site with and without memcache to try to reproduce the performance discrepancy from the load tests.
This benchmarking was sponsored by ITV.
| Comment | File | Size | Author |
|---|---|---|---|
| bench.php_.txt | 654 bytes | catch |
Comments
Comment #1
giorgio79 commentedWow, was just investigating whether to go with memcached or not, but based on this benchmark I may be much better off with Boost and a CDN.
Comment #2
thedavidmeister commentedBoost has it's own problems and it's performance improvements are limited to anonymous users only. It is *not* a drop-in replacement for the Drupal core caching system, it is an alternative to the core page-caching for anonymous users logic.
Modules like memcache are designed to replace the cache.inc file that ships with Drupal to move all/some/any of the core cache tables that are normally in the database to be handled by some other technology.
If you're looking for a file-system based cache that still uses Drupal's core caching system (Boost is based in the file-system) then checkout http://drupal.org/project/filecache for D7.
Edit: Be aware that you can use memcache and Boost in tandem as they are accomplishing totally different things (for the most part). The main point of this benchmark thread is that memcache clearly outperforms the D7 database caching and that relying on the D7 database caching for anything seems pretty lazy and "a bad idea" when it's never been easier to swap out cache bins for alternative, faster caching methods.
Comment #3
giorgio79 commentedActually, I just did a Boost + File Cache benchmark this weekend: #1737264: Simple Apache Benchmarks - Spectacular, and I experienced a massive speed improvement. While File Cache is file-based caching, it is also a close alternative to memcache, as it can use the memory file system. Would be great to see a more professional benchmark comparing memcache and file cache. Some say File Cache is even faster then memcache since file based caching uses linux file sockets, while memcache is most of the time TCP since it is usually on a different server...
Comment #4
thedavidmeister commentedwouldn't it be fairer to compare memcache to filecaching using the same server?
Comment #5
giorgio79 commentedFor a benchmark sure. For hosting, where you may not have enough mem it's not about fairness, but cost plus maintenance time. For File Cache it took me 3 lines of code to insert in settings.php...No need to read lengthy wikis, or pay for someone to set it up...
Comment #6
thedavidmeister commentedOh yeah absolutely, if that's your use case (and I'd say it is for most people, especially on shared hosting where memcache is not really an option) then I agree with you. Our in-house distro has filecache in it by default for all our new clients since it's such an easy win. Sometimes though, you do have the luxury/project requirements to shop around so it's a good thing to learn how to setup the various options and have benchmarks to reference. The important thing is to be comparing apples to apples from the start though or you can't really make a good decision about anything.
I'm not sure how convinced I am of the OP's assertion that memcache is slower than the database for D6 so I wouldn't want to include it in documentation verbatum; I've seen sites where performance was improved over the database quite dramatically in D6.
I'm not an expert on benchmarking these things but the problem with the OP's methodology that I see is that it is apparently assuming the database is doing nothing but getting and setting cache variables. In more "real world" examples I'd say it is pretty easy to create a site with enough traffic and big, expensive Views queries that the database gets overloaded and the performance of the database cache would degrade more quickly in that case than the memcache cache.
I'd love to see a centralised place where we can dump benchmarks with steps to reproduce and what is being simulated in each. For now I'll link what I've found elsewhere:
http://drupal.org/node/1098706
http://groups.drupal.org/node/135989
Comment #7
jeremy commentedThis ticket is quite outdated now, as we're approaching 7.x-1.4 and perform regularly benchmarking during development and before each release.