Hi Eirc,

Am Samstag, den 29.10.2005, 19:20 +0800 schrieb eirc dai:[...]

I suppose, you simply run out of file descriptors. Most Unices will
force pound to deal with a fixed amount of fds. This is usually 1024 fds
to fit all of pound's needs. Every open file, open port and connection
is handled by such a file descriptor, so rising the maximum value should
make you problem disappear.

Try using ulimit -a to evaluate the currently set value, i.e.:

# LANG=C ulimit -a|grep "^open files"
open files                      (-n) 1024

Evaluate a practical max. number of fds. Appreciate there are always at
least 2 fds needed for every single connection, as both the incomming
tcp requests as well as the outgoing connection to the backend needs to
be handled. Be aware that a higher amount might lower your performance
(depending on your OS kernel implementation, configuration and version),
although not drastically compared to the power needed for SSL
de-/encryption. As a rule of thumb use something like:

10 + (<amount of concurrent connections> * 2 * 1.5)

This calc allows for 10 fds for pound's syslog etc. plus the concurrent
connections you want to handle and adds 50% backing for peak-times.

Now set a higher limit value using ulimit -n:

# ulimit -n <new value>

Restart pound from the same shell, it should inherit the new ulimits
from the shell.


Best regards,
// Veit Wahlich

PS:
http://www.metacon.ca/ascii/ ;)

On Sat, 2005-10-29 at 19:20 +0800, eirc dai wrote:[...]

I'm not sure I would call that "poor performance". 500 concurrent
requests can be quite a bit - if that's what it is. It is more common to
measure performance in requests per second...
[...]

You may want to at least upgrade your system to something newer. With
Linux the transition from 2.4 to 2.6 made a big difference in the
threading behaviour (search this list for NPTL).[...]

Am Sonntag, 30. Oktober 2005 18:19 schrieb Lars Ohlén:[...]

you really should read the website, the man page, and search through the 
mailing list archive, should help you with most of your questions...


Cheers, Sascha
[...]

Just for follow up...

 

You might be able to do something tricky, like use the ha_port on a backend
port that coldfusion already uses, to check for connectivity.

 

See this technote:

http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_18336
<http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_18336>


 

Maybe what I would do is turn on the internal webserver on port 8500, and poll
that.  That way, you're hitting the coldfusion server directly.  It all depends
on what types of failures you want to detect.

 

You can turn on the internal webserver by editing your jrun.xml in cf_root
/runtime/servers/default/SERVER-INF/jrun.xml  (or coldfusion/SERVER-INF if
you're CFMX7), searching for jrun.servlet.http.WebService, and setting the
deactivated value to false.

 

Good luck, let me know what works for you.  (since I'm a CFMX shop too)

 

Joe

 
[...]

The other thing that might happen, especially with IP affinity is that
AOL in particular has a farm of web proxies.  Anytime an AOL user hits
your website, it goes through their web proxy first, and since they have
a couple different ips, the IP could change.  I've seen it happen on our
apps.  It's pretty annoying.

We moved to Cookie based affinity, so that's not a problem for us
anymore.
Joe
[...]
new[...]
some[...]
configured... I[...]
hashed[...]
high[...]
best on[...]
your[...]
will[...]
modest[...]
great[...]
noticing[...]
can't[...]
maintained[...]
no[...]
and[...]
ideas?[...]
questions.[...]
pound(at)apsis.ch.[...]