Scaling out memcached

Andreas Vierengel avierengel at gatrixx.com
Wed May 25 00:14:21 PDT 2005


Am Mittwoch, den 25.05.2005, 15:57 +0900 schrieb Batara Kesuma:
> Hi,
> 
> I have been using memcached for a few months, and very happy with its
> performance. Recently I just added some more mod_perl machines, we now
> have about 25 mod_perl, with each server running 50 processes. I just
> realized that memcached server has 1024 max connection limit, and I just
> bumped into this limit. 
> 
> Adding more memcached server is useless because each memcached server
> has to hold persistent connections with all mod_perl servers x
> processes.  It means that each memcached server has to hold 25 x 50 = 
> 1250 connections.
> 
> Is it better to set higher value (say 2048) for max connection, or is it
> better to stop using persistent connection? Is it possible to use normal
> connection instead of persistent connection? What about the cost
> penalty?

I would say that you only have a penalty if memcached/libevent uses
select() or poll(), because they are not scaling very well with
increasing number of fd's (persistent connections). If libevent uses
epoll (linux >= 2.6) or /dev/kqueue (BSD) than persistent connection
handling scales O(1).
If you are using linux, simply strace the memcached process and see if
it's doing epoll_wait(). If it does, you can bump up your
max-connections without problems. If not: well upgrade du kernel-2.6 :)
or if you already have, force libevent to use epoll.

See: http://www.monkey.org/~provos/libevent/

Hope that helps.

--Andy



More information about the memcached mailing list