2 ms·
I was a little surprised to get to the end of this and see no discussion of actual asynchronous web servers, using non-blocking i/o rather than threads. I writ
by abstractbill 19y ago
I was a little surprised to get to the end of this and see no discussion of actual asynchronous web servers, using non-blocking i/o rather than threads. I write such things often, using twisted. It's easy to handle a few thousand concurrent requests that way, but it doesn't seem to be an approach that's widely used for whatever reason.
- axod 19y agoAgreed. Even Apache supports a variety of other models with its mpm modules. You don't have to stick to the defaults even if you do use Apache.
- jmtulloss 19y agoI was also surprised he doesn't mention this. One thing that holds true, however, is that a browser won't make another request to a single server if two requests are still outstanding. So if, say, you have a COMET connection open and a long running server side AJAX request, none of your other AJAX requests will run. This might make the interface appear to hang, regardless of how many connections your web server can handle. I would say the general idea of returning quickly is probably a good one. I'm sure a lot of you have seen this already, but I love it: http://www.sics.se/~joe/apachevsyaws.html http://www.sics.se/~joe/apachevsyaws.html
- wmf 19y agoVery few people write Web servers or other networking code; they just write code that plugs into some existing Web server (usually Apache) or framework (e.g. Rails).