3 ms·

Even a $5 VPS can easily handle like 10k page views per minute if you use a performant web server i.e. not PHP or Ruby. Or even those with caching.

_joel 5y ago
Caching is the key here, it could still be making database requests which are blocked, unless it's using async.
- repsilat 5y ago
  DB queries in blogs (especially with this kind of traffic spike) are super correlated, you probably don't even need a cache if you batch identical reads together when the requests arrive within say 10 or 100ms of each other. Not a common technique though. A proof of concept demo: https://github.com/MatthewSteel/carpool https://github.com/MatthewSteel/carpool
handrous 5y ago
> use a performant web server i.e. not PHP or Ruby. PHP in an ordinary deployment behind Apache2 or nginx is very fast. If you're writing a Web service and your top two criteria for the language are "fast" and "scripting language" and PHP doesn't at least make your short-list, you've likely screwed up. It's the one to beat—you pretty much have to go with something compiled to have a good chance of beating it at serving dynamic responses to ordinary Web requests, and even then it's easy to screw up in minor ways and end up slower. Persistent connections, sure, maybe you want something else, but basic request-response stuff? Performance is not a reason to avoid it, unless your other candidate languages are C++ or very well-tuned and carefully written Java or Go, something along those lines. Speed-wise, it is certainly in a whole other category from Ruby or Python (in fact, even "speedy" Nodejs struggles to match it). Now, WordPress is slow because a top design goal is that it's infinitely at-runtime extensible. And lots of PHP sites are slow for the same reason that lots of Ruby, or Node, or Python, or Java, or .Net, or whatever, sites are slow: the developer was very bad at querying databases.

_joel 5y ago

Caching is the key here, it could still be making database requests which are blocked, unless it's using async.

repsilat 5y ago
DB queries in blogs (especially with this kind of traffic spike) are super correlated, you probably don't even need a cache if you batch identical reads together when the requests arrive within say 10 or 100ms of each other. Not a common technique though. A proof of concept demo: https://github.com/MatthewSteel/carpool https://github.com/MatthewSteel/carpool

handrous 5y ago

> use a performant web server i.e. not PHP or Ruby. PHP in an ordinary deployment behind Apache2 or nginx is very fast. If you're writing a Web service and your top two criteria for the language are "fast" and "scripting language" and PHP doesn't at least make your short-list, you've likely screwed up. It's the one to beat—you pretty much have to go with something compiled to have a good chance of beating it at serving dynamic responses to ordinary Web requests, and even then it's easy to screw up in minor ways and end up slower. Persistent connections, sure, maybe you want something else, but basic request-response stuff? Performance is not a reason to avoid it, unless your other candidate languages are C++ or very well-tuned and carefully written Java or Go, something along those lines. Speed-wise, it is certainly in a whole other category from Ruby or Python (in fact, even "speedy" Nodejs struggles to match it). Now, WordPress is slow because a top design goal is that it's infinitely at-runtime extensible. And lots of PHP sites are slow for the same reason that lots of Ruby, or Node, or Python, or Java, or .Net, or whatever, sites are slow: the developer was very bad at querying databases.