reaching incoming connections queued max, what happens?

[Micah Anderson <mi...@riseup.net>]

I was interested to find out what would happen if spamd was totally
overloaded, so I set my --max-children=1 and --max-conn-per-child=1 and
then started hitting spamd with spamc and -t timeout values to see what happens. 
Essentially, each connection (simultaneously generated) took 1 second
longer than the previous and at the -t value the message was returned
unscanned. I believe this is what could be expected. 

According to the spamd man page:

     -m number , --max-children=number
     This option specifies the maximum number of children to spawn.

     Incoming connections can still occur if all of the children are busy, however those 
     connections will be queued waiting for a free child.  

     Please note that there is a OS specific maximum of connections that can be queued 
     (Try "perl -MSocket -e’print SOMAXCONN’" to find this maximum).

This leads me to wonder what would happen if I hit my SOMAXCONN with
incoming messages, would they not be queued up? The SOMAXCONN on my
linux box appears to be 128. So to test, I did the following on my spamd server, 
and then restarted spamd:

echo "5" > /proc/sys/net/core/somaxconn

I then issued 15 simultaneous connections with the -t value set to 15.
Each individual connection took one second longer than the previous, as
before, and those connections that took over the -t value were returned
unscanned, as before. What puzzles me however is the fact that all of
the connections acted just as before, when the SOMAXCONN was set to 128.
Since each connection is coming in at exactly the same time I would
expect that the first one would get accepted by spamd, 5 connections
would be queued up, and then the 6+ connections would not be queued up
and something would happen, but it doesn't, its the same as before...
odd.

These are the time results for each individual spamc connection:

1. real    0m1.267s
2. real    0m2.567s
3. real    0m3.986s
4. real    0m5.178s
5. real    0m6.461s
6. real    0m7.914s
7. real    0m9.090s
8. real    0m10.361s
9. real    0m11.738s
10. real    0m13.377s
11. real    0m15.033s -- returned un-scanned
12. real    0m15.026s -- returned un-scanned

Micah

Re: reaching incoming connections queued max, what happens?

[micah <mi...@riseup.net>]

On Fri, 28 Sep 2007 13:01:23 -0400, Micah Anderson wrote:

> This leads me to wonder what would happen if I hit my SOMAXCONN with
> incoming messages, would they not be queued up? The SOMAXCONN on my
> linux box appears to be 128. So to test, I did the following on my spamd
> server, and then restarted spamd:
> 
> echo "5" > /proc/sys/net/core/somaxconn
> 
> I then issued 15 simultaneous connections with the -t value set to 15.
> Each individual connection took one second longer than the previous, as
> before, and those connections that took over the -t value were returned
> unscanned, as before. What puzzles me however is the fact that all of
> the connections acted just as before, when the SOMAXCONN was set to 128.
> Since each connection is coming in at exactly the same time I would
> expect that the first one would get accepted by spamd, 5 connections
> would be queued up, and then the 6+ connections would not be queued up
> and something would happen, but it doesn't, its the same as before...
> odd.

Well I'll be... 

http://www.nntp.perl.org/group/perl.perl5.porters/2007/08/msg127373.html 
is a bug report that indicates that Socket::SOMAXCONN() seems to always 
return 128 on Linux, even though the value is dynamic and can be set and 
queried via /proc/sys/net/core/somaxconn.

Micah