5 ms·

To be fair, the trouble with a name like Hacker News is that the uninitiated don't know it's for programmers and entrepreneurs. And I never get people having a

To be fair, the trouble with a name like Hacker News is that the uninitiated don't know it's for programmers and entrepreneurs. And I never get people having a go about stuff like concurrent connections at amateurs, that's completely our fault. Why can't web servers stop acting like babies that need constant attention with some sort of mystical knowledge to stop them falling over when something new happens? Why is our software so brittle?

laumars 13y ago
Because hardware varies significantly. What's optimal on some systems is sub-par on others. Thus it takes a sysadmin to set up the server optimally. Also, most web farms these days are built with multiple nodes that serve ~500 concurrent requests (even multiple VMs performs better than one instance of Linux on the same hardware running bare metal) and load distributed across each node. So a 500 concurrent default is entirely reasonable. However all of the above is moot because she's running Apache on Debian - which does not default to 500 concurrent connections. That is a setting she's applied herself (or paid someone to set up). And for the record, I'm all for amateurs rolling their own web servers - I'm certainly not elitist in that regard. But the fact remains that some of this stuff is rather technical, so complaining that it isn't easy is like saying cars should be self-servicing and that we shouldn't need garages and engineers.
- vidarh 13y ago
  But a lot of these limits could default to automatically adjust. Serving much more than 500 concurrent requests for static content is rather trivial on most remotely modern hardware if the software is designed for it. And reasonable queuing behaviour for sites have been possible for well over a decade. E.g. Eddie is 14 years old (http://eddie.sourceforge.net/txt/WP_1.0.html http://eddie.sourceforge.net/txt/WP_1.0.html - see the "Quality of Service" section in particular - while Eddie is intended for clustered setups, there are many situations where this approach is amenable even to single server setups) and provides a solution (amongst others) where if the system can't handle the incoming traffic, rather than serving up the main page and choking on assets and failing miserably in serving up anything to anyone, you can serve up a small light "queue" page and grant access to the full site as and when capacity allows. There are certainly plenty of things that truly does require a lot of technical skill to sort out, but a lot of software have poor defaults and lacks relatively straightforward features that would make the out of the box experience tremendously much better for less technical users.
  - laumars 13y ago
    > But a lot of these limits could default to automatically adjust. No. I do not want my server hardware attempting to guess optimal performance. I'd rather do that myself and know that it's set up correctly. You wouldn't buy a sports car then moan that it's a manual gear box and lacks cruise control. Just as you wouldn't run an automated tool to master a studio recording before sending the master off for CD pressing. If people want guesswork then don't install professional tools (sane defaults are another issue though - I just object to pro-tools applying guesswork). > And reasonable queuing behaviour for sites have been possible for well over a decade. Apache does queue TCP/IP connection requests. "Sorry pages" should be configured on the load balancer rather than HTTP daemon as the whole point of them is to offload the work from the saturated nodes. > There are certainly plenty of things that truly does require a lot of technical skill to sort out, but a lot of software have poor defaults and lacks relatively straightforward features that would make the out of the box experience tremendously much better for less technical users. A lot of software does have crap defaults, like how Apache publishes it's version number and the underlying OS by default (the ServerTokens directive). However the examples given (concurrent connections and sorry pages) are not wrong (her concurrent connections is set to a non-default value and sorry pages don't belong on the HTTP daemon because they're supposed to bypass the load)
    - dllthomas 13y ago
      "No. I do not want my server hardware attempting to guess optimal performance. I'd rather do that myself and know that it's set up correctly." Parent said "default to automatically adjust" - and I see no reason it shouldn't. You could still manually tweak all you want.
      - laumars 13y ago
        The automatic adjust option would be a crap default though. Just the process of Apache checking whether a page is static or dynamic means accepting the connection to begin with - by which point it would be too late to forward the connection to a sorry page if content is dynamic. It would also mean that connections end up stacking at a far greater rate as Apache is required to open each and every request just to identify teh requested file. The whole process would just break servers that are already under heavy load and serves no purpose what-so-ever on servers that aren't stressed. And since this whole argument is about how software should ship sane defaults, Apache is definitely doing the right thing by not including such nonsense by default. Believe me when I say that I'd welcome such a routine if it was practical as it would save me weeks of my life from load testing and fine tuning. But it just wouldn't work in practice.

laumars 13y ago

Because hardware varies significantly. What's optimal on some systems is sub-par on others. Thus it takes a sysadmin to set up the server optimally. Also, most web farms these days are built with multiple nodes that serve ~500 concurrent requests (even multiple VMs performs better than one instance of Linux on the same hardware running bare metal) and load distributed across each node. So a 500 concurrent default is entirely reasonable. However all of the above is moot because she's running Apache on Debian - which does not default to 500 concurrent connections. That is a setting she's applied herself (or paid someone to set up). And for the record, I'm all for amateurs rolling their own web servers - I'm certainly not elitist in that regard. But the fact remains that some of this stuff is rather technical, so complaining that it isn't easy is like saying cars should be self-servicing and that we shouldn't need garages and engineers.

vidarh 13y ago
But a lot of these limits could default to automatically adjust. Serving much more than 500 concurrent requests for static content is rather trivial on most remotely modern hardware if the software is designed for it. And reasonable queuing behaviour for sites have been possible for well over a decade. E.g. Eddie is 14 years old (http://eddie.sourceforge.net/txt/WP_1.0.html http://eddie.sourceforge.net/txt/WP_1.0.html - see the "Quality of Service" section in particular - while Eddie is intended for clustered setups, there are many situations where this approach is amenable even to single server setups) and provides a solution (amongst others) where if the system can't handle the incoming traffic, rather than serving up the main page and choking on assets and failing miserably in serving up anything to anyone, you can serve up a small light "queue" page and grant access to the full site as and when capacity allows. There are certainly plenty of things that truly does require a lot of technical skill to sort out, but a lot of software have poor defaults and lacks relatively straightforward features that would make the out of the box experience tremendously much better for less technical users.
- laumars 13y ago
  > But a lot of these limits could default to automatically adjust. No. I do not want my server hardware attempting to guess optimal performance. I'd rather do that myself and know that it's set up correctly. You wouldn't buy a sports car then moan that it's a manual gear box and lacks cruise control. Just as you wouldn't run an automated tool to master a studio recording before sending the master off for CD pressing. If people want guesswork then don't install professional tools (sane defaults are another issue though - I just object to pro-tools applying guesswork). > And reasonable queuing behaviour for sites have been possible for well over a decade. Apache does queue TCP/IP connection requests. "Sorry pages" should be configured on the load balancer rather than HTTP daemon as the whole point of them is to offload the work from the saturated nodes. > There are certainly plenty of things that truly does require a lot of technical skill to sort out, but a lot of software have poor defaults and lacks relatively straightforward features that would make the out of the box experience tremendously much better for less technical users. A lot of software does have crap defaults, like how Apache publishes it's version number and the underlying OS by default (the ServerTokens directive). However the examples given (concurrent connections and sorry pages) are not wrong (her concurrent connections is set to a non-default value and sorry pages don't belong on the HTTP daemon because they're supposed to bypass the load)
  - dllthomas 13y ago
    "No. I do not want my server hardware attempting to guess optimal performance. I'd rather do that myself and know that it's set up correctly." Parent said "default to automatically adjust" - and I see no reason it shouldn't. You could still manually tweak all you want.
    - laumars 13y ago
      The automatic adjust option would be a crap default though. Just the process of Apache checking whether a page is static or dynamic means accepting the connection to begin with - by which point it would be too late to forward the connection to a sorry page if content is dynamic. It would also mean that connections end up stacking at a far greater rate as Apache is required to open each and every request just to identify teh requested file. The whole process would just break servers that are already under heavy load and serves no purpose what-so-ever on servers that aren't stressed. And since this whole argument is about how software should ship sane defaults, Apache is definitely doing the right thing by not including such nonsense by default. Believe me when I say that I'd welcome such a routine if it was practical as it would save me weeks of my life from load testing and fine tuning. But it just wouldn't work in practice.