Marcus Rueckert <darix@opensu.se> 8/17/2010 12:44 PM >>> On 2010-08-17 12:37:01 -0600, Matthew Ehle wrote: I highly doubt that apc cache is much faster than memcached.
It mostly depends on how the wiki is used (amount of read vs. write), but the general consensus is that APC is slightly faster for most situations.
As the former co maintainer of the wiki I know very well that the cache access was the fastest part of it. :)
In a proper config you got one memcached per webserver, and configure all memcacheds in the wiki.
Each web server has its own memcached daemon, which is used by only that web server. We can always pool them, but it would make very little difference for our setup.
well, except that you cache things multiple times and might hit stale caches that way. I would recommend to configure it to use all running mecacheds
It's true that it might not be the most efficient use of memory, but there is tons to spare on these servers. As for stale caches, this hasn't really been an issue unless there has been a outage or schema change in the database, and that would be an issue no matter how we have memcached set up.
a) you got shared storage, no matter on which webserver you get the request. I would assume that the APC is local to the machine. Yes, and that is why it is slightly faster. APC is accessed locally, while memcached is accessed through a network socket, even on localhost.
1. access via localhost is shortcutted in the kernel for tcp. so if you only use it via localhost the overhead is pretty low.
Yep, exactly why I have been running memcached in the way that I have. It cuts out a lot of latency. My understanding is that even localhost binds still carry some latency.
if you want to keep the localhost only solution, the recent memcached versions support listening on a unix domain socket (see -s param).
Yes! Thank you, that pretty much takes care of any possible advantage that APC would have. The nice thing here is that if we need to scale up, it would be a very easy change to run memcached back in network mode.
anyway ... I think we are far away from the workload that warrants the switch to udp.
In all honesty, we are only talking about differences in the milliseconds anyways. The time used by a TCP handshake is pretty small when compared to the caching and compression options. However, why let a perfectly good LoadRunner license go to waste? :)