Assuming 10,000 hits per hour, that would be 167 hits per minute or roughly 20s per request. I would assume that every decent webserver can serve 1 hit/s without problems no matter the backend.
Of course, depending on the work you do to render a page, rendering the data for display can take a bit longer, so even if your webserver can serve 1 hit/s (likely, more), you may want to have more than one CPU processing requests, and you likely want to cache data wherever possible. But nothing of this would "require" NodeJS, as both, PHP and Perl can do the same.
| [reply] |
Welcome james.hans,
More than likely, SQL will do more to limit the 'hits per hour' than Perl will. I have a high volume web application that builds 30-50K lines of HTML per request and Perl does it's part in 100 milliseconds or less per core. But why not bench-mark this for yourself. It will make your company feel a lot safer with the decision. And I know you will get a lot of help and encouragement here!
Good Luck...Ed
"Well done is better than well said." - Benjamin Franklin
| [reply] |
james.hans:
As I understand it, JavaScript doesn't run any faster than perl (in fact I think that perl is still faster than JavaScript). So if there's a performance problem with perl, Angular isn't going to fix it. Both perl and JavaScript have some pretty interesting features, but I think perl comes out on top. Of course, you need to take this with a grain of salt, as I'm just starting learning JavaScript. (I hacked on it a little about 15 years ago, but didn't do anything significant.)
I don't use perl as the back end for websites, so I'll leave that part of the problem to the other monks.
...roboticus
When your only tool is a hammer, all problems look like your thumb.
| [reply] |
Since both Node and Perl (and PHP as well, since you brought it up) are interpreted instead of compiled (there is lots of discussion about what this actually means, but for this discussion, we're talking about the same thing.), the only advantage you will see is based in the native optimizations in whatever is running the code.
Unless your code and/or data access/storage is horribly inefficient, any of the mentioned technology should be able to scale to a reasonable number of hits an hour with no trouble on reasonable hardware. In my experience, usually for larger applications, your slowdown starts with the data, not the code manipulating it. Every time you have to fetch data, you have to tickle the disk. Disks are the bottleneck for most every operation done on the machine under normal usage.
This whiffs of premature optimization. Unless you're planning something that's going to need to serve more than 10000 hits per hour (a number I've just pulled from my nethers, mind you) on launch, work in whatever you're comfortable with. By the time you start scaling past that, you'll have a better understanding of what you've done wrong with the first iteration and how to improve it. Remember, there are VERY large enterprise sites running on PHP and Perl, as well as Node. Wikipedia and Facebook run on PHP and have enormous user bases. Slashdot, Amazon, and Craigslist run on Perl. LinkedIn and Uber are on Node.
In short, unless you're in an exceptional circumstance where you're going to be launching to a global audience that will actually be funneling large volumes of traffic very shortly after launch, don't sweat it. Focus on maintainability. If you have to struggle to issue an update, or build a brittle stack because you're still ramping on the chosen tool, you're going to have more problems than how many hits you deliver.
| [reply] |
Facebook, IIRC, translates PHP to C++ and compiles it for better performance: HipHop for PHP.
| [reply] |
| [reply] |