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