15 ms·

> "not good when your bottleneck is CPU" 99% of cases, your bottleneck will be I/O. In the 1% of cases where your webserver's bottleneck is the CPU, you have

> "not good when your bottleneck is CPU" 99% of cases, your bottleneck will be I/O. In the 1% of cases where your webserver's bottleneck is the CPU, you have much bigger problems than using a hipster ;) language: you're doing it wrong (tm) on an architectural level: (a) Your processor-intensive/long-running tasks need to be in seperate worker processes and (b) you need more webserver instances. I usually try to avoid absolute statements, but I think this may be accurate: The only CPU-intensive thing your web server code should ever do, is hash passwords.

yourad_io 12y ago
I shouldn't have tried to be funny on HN* . For this I apologize. Can I get a rebuttal to my points along with the downvotes, though? Is someone disputing that CPU intensive tasks should be moved off the webserver? Have you personally had experiences where your honest-to-$deity webserver bottleneck was the CPU? I'd be incredibly surprised. In most cases I'd guess you're underprovisioned and/or badly architected. * This is where we come to somberly discuss interesting things.
- nostrademons 12y ago
  You're assuming a number of things that aren't always true: 1. Your networking pipe into the server is slow. 2. You don't have a reverse proxy in front of the webserver to buffer the slow connections. 3. You don't make decisions about what information to show the user in the webserver; your UI isn't tailored for the particular user whose request you're servicing. 4. You haven't made productivity trade-offs to move work from the developer to the computer. Google's webservers (for Search) are CPU-bound, and I can guarantee that they are neither underprovisioned nor badly architected, and CPU-intensive tasks are moved off the webserver (the total amount of CPUs for webservers is miniscule compared to the number of CPUs used for the indexing & serving system). But Google has the fastest fiber networks in the world, a massive load-balancing infrastructure, its philosophy is to serve each user only the HTML/JS that they need (to cut latency), it relies heavily on A/B tests & experimentation, and it invests significantly in developer-productivity tools so that all the bookkeeping for the last two points are done by computers rather than humans.

yourad_io 12y ago

I shouldn't have tried to be funny on HN* . For this I apologize. Can I get a rebuttal to my points along with the downvotes, though? Is someone disputing that CPU intensive tasks should be moved off the webserver? Have you personally had experiences where your honest-to-$deity webserver bottleneck was the CPU? I'd be incredibly surprised. In most cases I'd guess you're underprovisioned and/or badly architected. * This is where we come to somberly discuss interesting things.

nostrademons 12y ago
You're assuming a number of things that aren't always true: 1. Your networking pipe into the server is slow. 2. You don't have a reverse proxy in front of the webserver to buffer the slow connections. 3. You don't make decisions about what information to show the user in the webserver; your UI isn't tailored for the particular user whose request you're servicing. 4. You haven't made productivity trade-offs to move work from the developer to the computer. Google's webservers (for Search) are CPU-bound, and I can guarantee that they are neither underprovisioned nor badly architected, and CPU-intensive tasks are moved off the webserver (the total amount of CPUs for webservers is miniscule compared to the number of CPUs used for the indexing & serving system). But Google has the fastest fiber networks in the world, a massive load-balancing infrastructure, its philosophy is to serve each user only the HTML/JS that they need (to cut latency), it relies heavily on A/B tests & experimentation, and it invests significantly in developer-productivity tools so that all the bookkeeping for the last two points are done by computers rather than humans.