You can always rewrite it if needed. A tactical rewrite of specific heavily-used routes that cuts out unnecessary abstractions often doesn't take too long and g

You can always rewrite it if needed. A tactical rewrite of specific heavily-used routes that cuts out unnecessary abstractions often doesn't take too long and gets most of the benefit. I can't see even a slow interpreted language being unable to process 100 requests/second. That leaves like 40 million clock cycles per request. Especially since they tend to come with built-in bytecode compilers, and most of the pure algorithmic code is written in C. Most web requests just don't take that much work to answer. Most performance issues I see with web applications are somebody writing ORMTable->find(x) in a loop or the equivalent, and then papering it over with a cache(or 3). Or memory leaks. Or badly-written SQL queries(no index, too many indices, disabling seq scans, using CTEs to elegantly 'refactor' SQL, etc.). Or doing blocking calculations/service requests as part of the original web request. The underlying language is almost never what's holding them back.