Hello again,

we have a problem with our load balancing server. I think we hit some
upper bound of pound. It seems that pound is not able to fork more
than about 1000 (possibly 1024) threads per second. Also the number of
context switches is impressive and in my opinion too large.
Is it possible to tune pound (or the system itself) to handle more
connections at once?

Some technical data of our load balancing server:
Pentium D 2.66 MHz (Dual Core, EM64T)
1 GB RAM
Linux 2.6.16.x (vanilla) on Debian Sarge AMD 64

Just look at the attached pictures to see our problems. ;-)

Maybe someone of you can help us.

Many thanks in advance

Bernhard J. M. Grün
gesichterparty.de

On Sep 12, 2006, at 3:41 PM, Bernhard Grün wrote:
[...]

What does 'ulimit -a' show for max open files?  And/or max user  
processes?

There's also some tweaking via /proc that you can do but 1024 sounds  
suspiciously like an open file max.

-Blake

[...]
I guess that some answers for maintainers and developers can be found in 
the following documents to consider design decisions.
- http://kegel.com/c10k.html
- http://www.cs.wustl.edu/~schmidt/ACE-papers.html

Regards,
Markus

In particular, this paper:
http://www.usenix.org/events/hotos03/tech/vonbehren.html

seems to provide a very good argument for threads (with a good cooperative
threading package).  That seems to be a better avenue for new development
than converting pound to an event model.


On 9/13/06 2:17 AM, "SF Markus Elfring"
<elfring(at)users.sourceforge.net>
wrote:
[...][...][...]

On Wed, 2006-09-13 at 00:41 +0200, Bernhard Grün wrote:[...]

The problem is you don't tell us what the log shows - Pound is usually
OK in showing the errors. Three possibilities:

- you may be running into the maximal number of threads limit - in quite
a few cases this is defined to be 1024. The solution is to recompile the
threads library (on Linux 2.6 this is part of libc) after changing the
#define. It sounds more difficult than it really is

- you may have a problem with the number of processes and/or open files
(check your ulimit)

- finally, if you see no errors, it may just be that you are approaching
your hardware limits (though it's unlikely)

BTW - what kind of monster web site do you run that needs more than 1000
requests/second?[...]

[...]
Would you like to look at alternative approaches?
Example: discussion "How many connections"
http://www.quickserver.org/forum/viewtopic.php?t=65

Which software component should be easier to configure for appropriate 
service settings?

Can a job queue help here?
http://en.wikipedia.org/wiki/Thread_pool_pattern

Regards,
Markus

[...]
How do you think about the experiences from another well-known approach 
with multi-processing modules?
http://httpd.apache.org/docs/2.2/mod/event.html

Regards,
Markus

I think that the Berkeley guys addressed the issue.

My experience is the same.  Event oriented code is fiendishly difficult to
get right and you wind up implementing something that looks like a
hand-rolled co-routine facility.  Much better to just write simple code that
works right and use a real user-level threading package.

You should also note that hardware architectures such as the recent ones
from Sun are moving towards many cores without increasing total CPU
throughput.  The reason is that having better hardware support for threads
is a bigger win than a faster (and hotter) single CPU.  I would guess that
pound would absolutely fly on a T-1000.  An event driven system would be
VERY difficult to get right.


On 9/22/06 9:30 AM, "SF Markus Elfring"
<elfring(at)users.sourceforge.net>
wrote:
[...][...][...]