> > server1:/tmp/pen-0.9.5# ./configure --with-poll --with-daemon
> > --with-fd-setsize=20000
> This doesn't work on Linux: even if FD_SETSIZE is redefined, select()
will
> still use the default.
I thought if I configure and compile pen --with-poll, select() would not
be used and poll() would be used instead?
> You'll probably have more luck on OpenBSD.
Yes, in the meantime I got it running on OpenBSD with pen accepting
10.000 (995) simultaneous connections.
But this pointed me to another problem:
Using poll() on a large number of simultaneous connections, really takes
the breath out of even a modern hardware. By example, using 10.000
simultaneous connections on a FreeBSD machine with pen results in Pen
having to handle 20.000 pipes. On
http://www.kegel.com/dkftpbench/Poller_bench.html you can see a
benchmark for a Pentium III, 600 MHz on FreeBSD with poll() for 30.000
pipes. The benchmark shows that each poll() takes about 35ms to perform
in that scenario. Assuming we have a real low traffic setup with only 45
packets a second (but 20k open sessions), this would result in 99% load.
((45packets/s)*(22ms/paket)=0,99)
The machine would become unusable.
This is no problem of pen but just a problem of pen using select() or
poll(). Performance with select() is even much worse. As you can see in
the above link, kqueue would be the perfect solution, because kqueue
only takes 8 microseconds (0,008ms instead of 35ms with poll()) in that
scenario. I know that kqueue is available for BSD-like OSes only, but
wouldn't anyone here regard it as a good idea to implement kqueue in pen
as a configuration option? This would make pen really powerful even in
heavy scenarios.
Can I hope for anyone hacking this into pen? I'm no programmer, I'd do
it myself if I knew how but I've been told it's not too hard to do...
:-)
Regards,
Torsten
This archive was generated by hypermail 2.1.2 : Wed Sep 18 2002 - 11:30:36 CEST