There are just so, so many problems with these benchmarks. (This comment from the author of Servant, a Haskell framework, nicely sums up a lot of the criticism: https://www.reddit.com/r/haskell/comments/6b3dlt/techempower...) But cherry picking the single query benchmark in particular makes the issue worse. Like... how many web apps do you stand up where you have one client you want to serve? At least the "multiple requests" benchmark is sort of plausible for the kind of workload you'd want to handle.

In most cases, though, you care a lot more about the 95th or even 99th percentile response times than you do the mean; I'd trade quite a bit percentage-wise off my mean response time if it brought the 95th percentile way down.

(This isn't to hate on PHP; PHP is fine. But you shouldn't choose it because the "single query" benchmark says it's fast.)

While I agree that benchmark are somehow problematic, many of the critisms in the Reddit comment are pretty void once we do not targets a browser or theory. When I have an IoT device I do not care about content negotiation or the content type. I send my stuff up using some HTTP I use.

Is it fair in the comparison? Nope. Comparing oranges with apples is always bad. The question however is whether you want an Apple or an Orange?

TechEmpower has to be read like that: plaintext ensures the HTTP server stack and the base runtime. Json is about json encoding and emitting. Single query and multiple query about streaming data through. The benchmark is gradually testing your platform. .NET Core was bad at Plaintext. Now they are top 10. Now they realized the default json library (Newtonsoft.Json) of .NET is very nice but too slow. So they built a new one (System.Text.Json). Now the PostgreSQL Driver sucks. So they find and support the driver project. Like that you built a platform which is top notch.

> Like... how many web apps do you stand up where you have one client you want to serve?

I think you confused "single query" with "single request". The goal of the benchmark is to make one query to the DB per request. The number of requests (clients) is in the hundreds of thousands.

That is a bit misleading: Let me explain...

#11 in Single Query is: Swoole, PHP, mySQL

Swoole => Not default PHP but a highly specialized framework Single Query => This is not about fast language/runtime but fast DB driver

While still definitely impressive, Techempower Plaintext is more specific (runtime + http server). Here Swoole/PHP is #60. The Swoole/PHP mysql driver (that is not default PHP mysql driver) is very optimized compared to e.g. the .NET Core postgreSQL driver. The result => Swoole/PHP is wicked fast (~ 15% delta) but .NET Core beats Swoole/PHP Plaintext (~ 75% delta).

Plain traditional PHP is not one of the fastest language/runtime. But Swoole is a wicked fast framework.

Good thing however: Indeed, the JIT will improve the PHP language/runtime. And Swoole shows what is possible if you make some radical design decisions (same what happened with .NET). And this is good for PHP.

I don't really understand that benchmark. How can swoole (#11), written in PHP, be faster than PHP itself (#125)?

Swoole hijacks network I/O from Zend Engine. Thus, it's capable of performing async I/O while keeping the userland code the same. What the benchmark shows is what happens when there's non-blocking I/O when speaking to the DB. PHP's problem is its synchronous nature, but Swoole easily bypasses that limitation.

Btw. Swoole is not written in PHP. It's C++. It's compiled as an extension for PHP.

Because it's not PHP it's C++.

Because Swoole is a framework with an independent HTTP server and mysql driver. If you get rid of this two, it is just the algorithmic power of the runtime of PHP which factors in here.

swoole is co-routine based, having a much better lifecycle and resource sharing as a consequence. Which leads to much more throughput.

Is there a key for the different language colours? I figure PHP is blue because of Swoole, but the rest are just a sea of colours I have to Google the web framework of to find the language (on mobile at least).

There's a column called "Lng" that shows an abbreviation of the language.