3 ms·
The call for great quantities of hard evidence that is occuring on both sides is both entirely reasonable and utterly unrealistic. These are two good developer
by bandushrew 16y ago
The call for great quantities of hard evidence that is occuring on both sides is both entirely reasonable and utterly unrealistic.
These are two good developers who are drawing on their real life experiences to develop their opinions, backed up with some simple tests performed on local machines.
While it would be pleasant if they could provide hard data for a wide range of webservers to 'prove' their opinions it is hardly a realistic option for either of them without investing a degree of time and effort that is far greater in scope than the work being discussed.
I would prefer to see less of a cry for hard evidence of real life usage patterns from either side, and a greater acceptance of the fact that this is simply an interesting discussion of technical possibilities by some good developers.
- jacquesm 16y agoI've given what data that I have easy access to (from a single threaded asynchronous home brewn server that sees an awful lot of traffic) in that other thread. Now that's a special enough case that I think that the conditions under which normal servers operate will be skewed considerably in the downward direction compared to that one and even there I never observed an active-to-total ratio of more than 40% over a span of 5 minutes during a 2 hour run. Instrumenting varnish or apache would be a lot harder to do because I don't know those code bases well enough to know for sure that I'm doing it just right so all I can rely on there is the data reported by the 'status' modules of those programs, and for now neither of those suggest otherwise. Zed attacks that data with a bunch of handwaving but to date has yet to show a single instance of a server which actually has an active-to-total ratio that is higher than 60%. I suspect such servers do exist, media servers, file servers and other other servers with relatively few connections, a large worker pool compared to the number of active connections and lots of long files being shipped across those connections. But your typical web server is more likely to be stuck in an endless cycle of accept-read-write-close where both the 'read' and the 'write' can block for significant amounts of time compared to the number of bits shipped, and the backend can do the same thing once more. So idle is the norm.