Laszlo Nagy writes:
> but a threaded server cannot handle 100+ simultaneous (long running)
> requests, because that would require 100+ threads to be running.
On a reasonable server these days, 100 threads seems to be no big deal.
I've run several times that many. I think things get ragged at a f
What's wrong is the 1,135,775 calls to "method 'poll' of
'select.epoll' objects".
I was affraid you are going to say that. :-)
With five browsers waiting for messages over 845 seconds, that works
out to each waiting browser inducing 269 epolls per second.
Almost equally important is what the
Laszlo Nagy wrote:
[...]
> And here is my problem. If I point 5 browsers to the server, then I get
> 2% CPU load (Intel i5 2.8GHz on amd64 Linux). But why? Most of the time,
> the server should be sleeping. cProfile tells this:
>
> ncalls tottime percall cumtime percall filename:lineno(func
JavaScript clients (browsers) do long poll requests. Each request can
take up to 10 seconds before the server responds. On the server side,
every client has a queue of messages that needs to be sent to the
client. When the long poll request comes in, the server checks if there
are messages to b
