You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "Dr. Peter Poeml" <po...@suse.de> on 2007/02/21 12:24:41 UTC
apr_memcache and sockets in TIME_WAIT
Hello,
I have written an Apache module which uses apr_memcache. While
benchmarking with e.g. "ab -n 5000 -c 40", I find that there are lots of
sockets in TIME_WAIT after each test:
tcp 0 0 127.0.0.1:11211 127.0.0.1:59866 TIME_WAIT -
tcp 0 0 127.0.0.1:11211 127.0.0.1:60125 TIME_WAIT -
tcp 0 0 127.0.0.1:11211 127.0.0.1:59860 TIME_WAIT -
# netstat -tupan | grep 11211 | grep WAIT | wc -l
3057
Apache is running in worker mode with thread_limit=64. The behaviour is
the same with prefork mode.
According to the memcache stats, curr_connections alternates quickly
between 3 and about 40.
I wonder if I'm doing something wrong. I have basically copied the code
from ssl_scache_memcache.c. My expectation would be that connections are
kept open and reused.
I create the server like this:
ap_mpm_query(AP_MPMQ_HARD_LIMIT_THREADS, &thread_limit);
apr_memcache_server_create(p, host_str, port, 0, 1, thread_limit, 600, &st);
Any idea?
Thanks,
Peter
--
SUSE LINUX Products GmbH Bug, bogey, bugbear, bugaboo:
Research & Development A malevolent monster (not true?);
Some mischief microbic;
What makes someone phobic;
The work one does not want to do.
From: Chris Young (The Omnificent English Dictionary In Limerick Form)
Re: apr_memcache and sockets in TIME_WAIT
Posted by "Dr. Peter Poeml" <po...@suse.de>.
On Wed, Feb 21, 2007 at 12:24:41PM +0100, Dr. Peter Poeml wrote:
> Hello,
>
> I have written an Apache module which uses apr_memcache. While
> benchmarking with e.g. "ab -n 5000 -c 40", I find that there are lots of
> sockets in TIME_WAIT after each test:
>
> tcp 0 0 127.0.0.1:11211 127.0.0.1:59866 TIME_WAIT -
> tcp 0 0 127.0.0.1:11211 127.0.0.1:60125 TIME_WAIT -
> tcp 0 0 127.0.0.1:11211 127.0.0.1:59860 TIME_WAIT -
>
> # netstat -tupan | grep 11211 | grep WAIT | wc -l
> 3057
>
> Apache is running in worker mode with thread_limit=64. The behaviour is
> the same with prefork mode.
>
> According to the memcache stats, curr_connections alternates quickly
> between 3 and about 40.
>
> I wonder if I'm doing something wrong. I have basically copied the code
> from ssl_scache_memcache.c. My expectation would be that connections are
> kept open and reused.
>
> I create the server like this:
> ap_mpm_query(AP_MPMQ_HARD_LIMIT_THREADS, &thread_limit);
> apr_memcache_server_create(p, host_str, port, 0, 1, thread_limit, 600, &st);
^^^
It turns out that the behaviour is more or less to be expected -- with
the softmax value of 1 that I was using here. With softmax =
thread_limit there is no socket in TIME_WAIT at all, after the
benchmark.
Also, Paul pointed me to the fact that softmax=1 and hardmax=1 will open
only a single connection, which is indeed reused, so in this case there
are also no sockets left in TIME_WAIT.
Thus, softmax=1 was not such a good idea in a many threads scenario.
Regards,
Peter
--
SUSE LINUX Products GmbH Bug, bogey, bugbear, bugaboo:
Research & Development A malevolent monster (not true?);
Some mischief microbic;
What makes someone phobic;
The work one does not want to do.
From: Chris Young (The Omnificent English Dictionary In Limerick Form)
Re: apr_memcache and sockets in TIME_WAIT
Posted by Matthew Kent <ma...@bravenet.com>.
On Wed, 2007-21-02 at 12:24 +0100, Dr. Peter Poeml wrote:
> Hello,
>
> I have written an Apache module which uses apr_memcache. While
> benchmarking with e.g. "ab -n 5000 -c 40", I find that there are lots of
> sockets in TIME_WAIT after each test:
>
> tcp 0 0 127.0.0.1:11211 127.0.0.1:59866 TIME_WAIT -
> tcp 0 0 127.0.0.1:11211 127.0.0.1:60125 TIME_WAIT -
> tcp 0 0 127.0.0.1:11211 127.0.0.1:59860 TIME_WAIT -
>
> # netstat -tupan | grep 11211 | grep WAIT | wc -l
> 3057
>
Having just looked at a similar issue in another context I stumbled
across http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/8929
which is further confirmed by
http://tangentsoft.net/wskfaq/articles/debugging-tcp.html #4
As to shortening that.. I have no clue :)
--
Matthew Kent \ SA \ bravenet.com