"Make it work, then make it fast!"
Benchmark-wise this simple solution is slow due to the overhead of fork(). Now I see why people came up with schemes where a server forks on stock, so at any given time a ready-made fork is idling for a request. This forking-solution here gets creamed by the former/problematic non-forking one in ab... | [reply] |
BTW: Can someone tell me why HTTP::Daemon, under stress-test, after a couple of hundred/thousand requests simply silently exits? With the client telling me "apr_socket_recv: Connection reset by peer (104)"?? (command ab -c 50 -n 5000 http://localhost:4242/ never reaches the 5000, always breaks at ~4800..)
What can I use to debug exits which do not produce an error?
| [reply] |
Can someone tell me why HTTP::Daemon, under stress-test, after a couple of hundred/thousand requests simply silently exits?....What can I use to debug exits which do not produce an error?
That is what its programmed to do.
See while condition while (my $c = $d->accept) {
accept, like every function can fail, and once it fails, it exits the loop and your program ends.
If you want to know why it ended, you'll have to check $!/$^E or poke around your HTTP::Daemon instance, maybe turn on $HTTP::Daemon::DEBUG...
or since connections can be reset for any reason, simply handle the error by restarting the accept loop.
| [reply]
[d/l] |