Performance gain with Memcached on Windows?
I just have tested memcached on Windows/Apache to investigate, if a performance can be expected.
I was very surprised, but it seems that memcached does not perform better than the Drupal built-in DB-Caching mechanism.
I am very curious, if anybody else had different results.
Detailed information follows.
My environment
- Windows XP
- Apache/2.0.61 (Win32)
- PHP Version 5.2.6
- MySQL 5.0.77
- Memcache 1.2.6
All installed on single box.
I have set up two environments with copies of the same DB.
- ENV_DB_CACHING - Caching provided by the Drupal built-in DB caching mechanism
- ENV_MEMCACHE
To set up Memcache on Drupal i followed these excellent Howtos and
- http://pureform.wordpress.com/2008/01/10/installing-memcache-on-windows-...
- http://drupal.org/project/memcache
Test: hitting a single node with Apache ab
Time per request
| Hitting a single node |
DB_CACHING |
MEMCACHE |
|---|---|---|
| Anonymous user |
349.156 [ms] |
361.681 [ms] |
| loggin-in user |
7107.957 [ms] |
7378.475 [ms] |
The results for the memached enabled site are slightly worse than the DB-cache enabled site.
Why? Any ideas?
Remark
From the results one could guess that memcache was not active. But the memcache stats shows the usage:
Memcache status
| Property | Wert |
|---|---|
| pid | 5192 |
| uptime | 35 Minuten 2 Sekunden |
| time | 12. May 2009 - 9:31 |
| version | 1.2.6 |
| pointer_size | 32 |
| curr_items | 127 |
| total_items | 145 |
| bytes | 321.13 KB |
| curr_connections | 2 |
| total_connections | 467 |
| connection_structures | 7 |
| cmd_get | 4318 |
| cmd_set | 145 |
| get_hits | 3749 |
| get_misses | 569 |
| evictions | 0 |
| bytes_read | 703.35 KB |
| bytes_written | 23.91 MB |
| limit_maxbytes | 160 MB |
| threads | 1 |
| hit_percentage | 86.82% |
| mem_used | 0.20% |
Detail results for Anonymous User hitting a node page
_NO_MEMCACHE_
D:\Apache2\bin>ab -c 5 -n 100 http://localhost/eclipse/DB_CACHING/en/node/6228
This is ApacheBench, Version 2.0.41-dev <$Revision: 1.121.2.12 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 2006 The Apache Software Foundation, http://www.apache.org/
Benchmarking localhost (be patient).....done
Server Software: MOD_ACCESS_ODBC/1.2.2
Server Hostname: localhost
Server Port: 80
Document Path: /eclipse/DB_CACHING/en/node/6228
Document Length: 26270 bytes
Concurrency Level: 5
Time taken for tests: 6.983111 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 2676800 bytes
HTML transferred: 2627000 bytes
Requests per second: 14.32 [#/sec] (mean)
Time per request: 349.156 [ms] (mean)
Time per request: 69.831 [ms] (mean, across all concurrent requests)
Transfer rate: 374.33 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 1.5 0 15
Processing: 187 342 64.4 328 532
Waiting: 78 162 45.1 156 344
Total: 187 342 64.6 328 532
Percentage of the requests served within a certain time (ms)
50% 328
66% 360
75% 375
80% 391
90% 422
95% 485
98% 516
99% 532
100% 532 (longest request)MEMCACHE
D:\Apache2\bin>ab -c 5 -n 100 http://localhost/eclipse/MEMCACHE/en/node/6228
This is ApacheBench, Version 2.0.41-dev <$Revision: 1.121.2.12 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 2006 The Apache Software Foundation, http://www.apache.org/
Benchmarking localhost (be patient).....done
Server Software: MOD_ACCESS_ODBC/1.2.2
Server Hostname: localhost
Server Port: 80
Document Path: /eclipse/MEMCACHE/en/node/6228
Document Length: 26270 bytes
Concurrency Level: 5
Time taken for tests: 7.233627 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 2676800 bytes
HTML transferred: 2627000 bytes
Requests per second: 13.82 [#/sec] (mean)
Time per request: 361.681 [ms] (mean)
Time per request: 72.336 [ms] (mean, across all concurrent requests)
Transfer rate: 361.37 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 2.6 0 15
Processing: 203 356 73.7 344 657
Waiting: 93 196 49.0 187 375
Total: 203 356 73.4 344 657
Percentage of the requests served within a certain time (ms)
50% 344
66% 375
75% 391
80% 407
90% 454
95% 516
98% 548
99% 657
100% 657 (longest request)Detail results for logged-in User hitting a node page
_NO_MEMCACHE_
D:\Apache2\bin>ab -c 5 -n 20 -C SESS51aed9db18cd16994fe6b6563879dace=1ii3fd372a21r4r7al8079lva7 http://localhost/eclipse/DB_CACHING/de/node/6228
This is ApacheBench, Version 2.0.41-dev <$Revision: 1.121.2.12 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 2006 The Apache Software Foundation, http://www.apache.org/
Benchmarking localhost (be patient).....done
Server Software: MOD_ACCESS_ODBC/1.2.2
Server Hostname: localhost
Server Port: 80
Document Path: /eclipse/DB_CACHING/de/node/6228
Document Length: 42576 bytes
Concurrency Level: 5
Time taken for tests: 28.431828 seconds
Complete requests: 20
Failed requests: 0
Write errors: 0
Total transferred: 859340 bytes
HTML transferred: 851520 bytes
Requests per second: 0.70 [#/sec] (mean)
Time per request: 7107.957 [ms] (mean)
Time per request: 1421.591 [ms] (mean, across all concurrent requests)
Transfer rate: 29.51 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 3.4 0 15
Processing: 5535 6816 628.9 6994 7841
Waiting: 5049 6548 654.3 6696 7543
Total: 5535 6817 630.2 6994 7856
Percentage of the requests served within a certain time (ms)
50% 6994
66% 7072
75% 7245
80% 7354
90% 7731
95% 7856
98% 7856
99% 7856
100% 7856 (longest request)MEMCACHE
D:\Apache2\bin>ab -c 5 -n 20 -C SESS68c3247f76759e36721541e071c15042=dhpqqddpbmmg9advlfar0553h0 http://localhost/eclipse/MEMCACHE/de/node/6228
This is ApacheBench, Version 2.0.41-dev <$Revision: 1.121.2.12 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 2006 The Apache Software Foundation, http://www.apache.org/
Benchmarking localhost (be patient).....done
Server Software: MOD_ACCESS_ODBC/1.2.2
Server Hostname: localhost
Server Port: 80
Document Path: /eclipse/MEMCACHE/de/node/6228
Document Length: 42697 bytes
Concurrency Level: 5
Time taken for tests: 29.513900 seconds
Complete requests: 20
Failed requests: 0
Write errors: 0
Total transferred: 861760 bytes
HTML transferred: 853940 bytes
Requests per second: 0.68 [#/sec] (mean)
Time per request: 7378.475 [ms] (mean)
Time per request: 1475.695 [ms] (mean, across all concurrent requests)
Transfer rate: 28.50 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 2 7.5 0 31
Processing: 5426 6915 616.0 7009 7888
Waiting: 5002 6594 611.1 6696 7637
Total: 5426 6917 618.0 7009 7888
Percentage of the requests served within a certain time (ms)
50% 7009
66% 7386
75% 7433
80% 7449
90% 7496
95% 7888
98% 7888
99% 7888
100% 7888 (longest request)Groups:
Login to post comments
I'm prepared to be shot down
I'm prepared to be shot down here, but I don't really think memcached makes anything faster if your database server can handle the load. There is still a network transaction, there is still a lookup and it still returns something. If your lookup is expensive, i.e. joins and some lack of indexability (new word!) in MySQL Memcached will look good straight away as it has cached the result.
However if MySQL is chugging away nicely and not chewing up CPU or disk time memcached won't make your site appear faster. Memcached only really kicks in as you scale up and removes some of the load that would have been database bound.
That is just my opinion
Memcache absolutely makes
Memcache absolutely makes things faster in certain conditions. First and foremost is that I would never setup memcache with one bin and on the same server. You are pretty unlikely to see too much gain there. And of course people have seen different results, otherwise nobody would use it if it makes your site slower ;)
It also depends on where the real bottleneck is on your site. Is this a stock Drupal site, if so, what version? It is very hard to look at these results as these numbers don't really mean anything unless there is some context.
Please feel free to check out and test the cacherouter module as well.
-s
@slantview I agree with your
@slantview I agree with your comments.
Also ducdebreme which version of Memcached are you using (this one? http://jehiah.cz/projects/memcached-win32/)
In general Memcached is fast on Linux because of kernel events made possible by libevent and epoll. Windows may have equivalents but when I last looked I couldn't see the windows port using realtime APIs. I thought it just emulated the functionality, get, put, delete e.t.c.
I looked at speeding up an old ColdFusion application with Memcached and the short answer was Memcached on Linux helped. On windows I got no joy.
My guess was that it's because of Windows ...
yes, there are big differences between Linux and Windows... e.g. in thread and process handling. May be that's the reason for not having a performance gain. But i am curious, if there is anybody out there, who realized a performance gain while using memcached on Windows....
Last weekend at the Swiss Drupalmediaconf someone said, that cache should be kept in the memory and not in a database. To me, this sounded very reasonable, and so i decided to make the test ...
@stewsnooze I used version 1.2.6 from http://code.jellycan.com/memcached/
86%
@ducdebreme
Well, you are getting 86% on cache hits, which is quite good. So cache misses is not your problem.
Having one bin is not a good strategy. Use different bins for different cache tables.
There are structural problems with the site though.
For Anonymous users you have 350+ ms using either type of cache. That is way too much, and should be in the 10-30 ms range when page cache is on, even with the database cache.
For logged in users you have 7 SECONDS. That is very excessive.
You have something that is consuming too much time. Look if you have something doing strange things in hook_init()/hook_boot(), or doing network I/O for every request.
Before worrying about memcache, solve these problems.
Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.
You won't see differences on 100 hits to the same node.
I would suggest you do a more realistic scenario to see real performance differences. For your test setup, you've probably got every notable query in the mysql query cache. The query cache is not too much slower than memcache.
Further, you're just loading a node--this is not something that benefits too terribly much from caching, outside the page cache, and you may be running a module that's preventing aggressive caching from working.
Also worth noting is that on our sites, we find that cache misses are a lot faster on memcache than on mysql. Mysql determining if a complicated view query is cached can take a little time, although pretty insignificant in the page generation times you're seeing. No such issues with memcache.
I would suggest you test with a complicated view that does a lot of node_loads on the same page, or even better test with multiple logged-in users at the same time, doing different stuff.
Lastly, this shouldn't even be an issue with anonymous users. Boost, boost, boost!
Ummm ....
The whole idea of caching is that the second (and subsequent) requests does not have to execute the PHP and database queries needed to construct the page. If all the requests are unique, or from logged in users, little benefit will be seen from caching. So, this is a valid scenario.
Your wording confuses "mysql query cache" with "page caching in mysql". They are not the same.
Caching in the database and in memcache are different. By caching in memcache, you relieve MySQL from handling those requests, and offload that to memcache. This allows the server(s) to handle more requests. So it is a scalability issue more than pure performance.
Even without aggressive caching, memcache gives a noticeable performance bump.
Boost is worth testing, but this is a Windows server, albeit with Apache. The 5.x version used symlinks, and those do not work on Windows. The 6.x version does not have this limitation but says that it is not well tested on Windows.
Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.
Hm, nope.. have to agree to
Hm, nope.. have to agree to bhuga.
On a rather basic Drupal site (such as in this test) all memcache does is deliver more or less the same data that Drupal's normal cache delivers. If those basic queries to the cache tables are covered by MySQL's query cache (which they should) it doesn't make much of a difference whether you go for Drupal's normal caching or memcache.
While you are right, that using memcache adds scalability to your setup, bhuga is right, that the test scenario used by the thread starter is not sufficient as is does not resemble a situation in which memcache can provide a reasonable benefit.
First time I used memcache (with a D5 installation) I had a situation similar to the test scenario with mostly anonymous traffic, some 86% memcache hit rate, no end-user performance gain at all, just because the machine wasn't anywhere near its limits and all those cache table querys from Drupal didn't have a negative impact on the other queries, so substituting them with memcache calls had no positive effects.
Alex
There's no confusion here :)
No, there's no confusion. Without memcache, a page cached in Mysql can either be in the query cache, or not. A page that is in the query cache will be returned much, much faster than one that Mysql has to pull from disk. Note that this is a layer of caching below Drupal's cache.
What I'm saying is that when a particular Drupal-cached page is in Mysql's query cache, the performance of returning that item is not significantly different than with memcache.
I completely agree. However, not with this scenario, in which we are using ab to load the same page over and over with a given level of concurrency, and with no other pages being loaded in-between. The query cache, with default parameters (64 megs), will take care of it all. That is why this is not a 'valid scenario' for displaying memcache performance benefits.