5 ms·

Interesting, thanks for the answer. What I would really like to see is the obligation to have in the name "Lithium-with_batch" and a version "Lithium" that woul

Interesting, thanks for the answer. What I would really like to see is the obligation to have in the name "Lithium-with_batch" and a version "Lithium" that would be without it. It would show the impact of other optimizations which are currently hidden by the paradigm shift. What would to you the other major optimizations?

matt42 6y ago
I added -pipeline but I guess -with-batch is more explicit. I'll change it then. But anyway the techempower team will eventually add a special tag for batching. There is actually a version of lithium not using batching, check for 'lithium-postgres' in the benchmark tabs other than 'composite score' Other big optimizations are - non blocking communications between the database and the framework - non blocking communication between the http client and the framework This is for C++, for other slower interpreted languages: calling C bindings is a big optimization aswell (and this is how some php frameworks get good performances for example).
- The_rationalist 6y ago
  Thanks. Asynchronocity is one thing but there is one thing that in theory can achieve better performance than asynchronicity alone: I'm referring to the reactive programming paradigm which benefit from the concept of backpressure. If you've heard of it, do you think it could achieve even better performance? https://medium.com/@jayphelps/backpressure-explained-the-flow-of-data-through-software-2350b3e77ce7 https://medium.com/@jayphelps/backpressure-explained-the-flo...
  - matt42 6y ago
    I had a look at the video, but I don't think there is backpresure in this benchmark since there is only 512 connections max and each connections wait for the server response before sending a new request. So in other words the load generator never send more request/s that the server is able to handle. (tell me if I missunderstood backpressure)
    - The_rationalist 6y ago
      Mmh then I wonder if the techempowerUp benchmark suite would benefit from a new benchmarck that is backpressure sensitive, thus increasing its coverage of real world workloads?
      - matt42 6y ago
        yes, it has been discused already to increase the number of connections. But still, several thousands of simultaneous connections is still ok for the best performing frameworks...

matt42 6y ago

I added -pipeline but I guess -with-batch is more explicit. I'll change it then. But anyway the techempower team will eventually add a special tag for batching. There is actually a version of lithium not using batching, check for 'lithium-postgres' in the benchmark tabs other than 'composite score' Other big optimizations are - non blocking communications between the database and the framework - non blocking communication between the http client and the framework This is for C++, for other slower interpreted languages: calling C bindings is a big optimization aswell (and this is how some php frameworks get good performances for example).

The_rationalist 6y ago
Thanks. Asynchronocity is one thing but there is one thing that in theory can achieve better performance than asynchronicity alone: I'm referring to the reactive programming paradigm which benefit from the concept of backpressure. If you've heard of it, do you think it could achieve even better performance? https://medium.com/@jayphelps/backpressure-explained-the-flow-of-data-through-software-2350b3e77ce7 https://medium.com/@jayphelps/backpressure-explained-the-flo...
- matt42 6y ago
  I had a look at the video, but I don't think there is backpresure in this benchmark since there is only 512 connections max and each connections wait for the server response before sending a new request. So in other words the load generator never send more request/s that the server is able to handle. (tell me if I missunderstood backpressure)
  - The_rationalist 6y ago
    Mmh then I wonder if the techempowerUp benchmark suite would benefit from a new benchmarck that is backpressure sensitive, thus increasing its coverage of real world workloads?
    - matt42 6y ago
      yes, it has been discused already to increase the number of connections. But still, several thousands of simultaneous connections is still ok for the best performing frameworks...