4 ms·

Add an endpoint with a poorly optimized SQL query: 20 concurrent connections. I find these benchmarks to not be very valuable. Typically the bottlenecks are in

Add an endpoint with a poorly optimized SQL query: 20 concurrent connections. I find these benchmarks to not be very valuable. Typically the bottlenecks are in the database, not in the web server/code. Even when it is in the code, optimizations only become truly valuable when you are at scale or doing something either horribly wrong or algorithmically unique.

tlrobinson 14y ago
In an asynchronous/event driven server slow SQL queries won't limit your concurrency, just latency. Memory consumption is what limits concurrency. CPU and bandwidth limits throughput. That said, I agree it's not a particularly useful benchmark.
- fernandezpablo 14y ago
  > In an asynchronous/event driven server slow SQL queries won't limit your concurrency Since this is on the JVM, SQL almost always means JDBC and JDBC is blocking so yes, SQL will in fact limit your concurrency.
  - shenedu 14y ago
    yes, SQL is blocking, JVM also have threads. The http-kit is asynchronous(epoll on linux), the API for programmers is sync, which is more familiar.
  - pygy_ 14y ago
    Alternatively, you can use a message queue or a REST service, and whatever lightweight, async database frontend.
    - fernandezpablo 14y ago
      That would just move the blocking code elsewhere, and now you have one extra framework / message queue on your stack (free complexity)
      - pygy_ 14y ago
        The point is to use a non-blocking DB frontend. Not necessarily JVM-based.
ptaoussanis 14y ago
Certainly your web server isn't likely to be the performance bottleneck in the majority of real-world applications. Even without a db call, just generating the response Clojure-side will kill your numbers (and Clojure is pretty darn fast). Still, the ability to cheaply handle large numbers of concurrent connections is great for things like WebSockets and long polling where you aren't crunching data for every connection all the time. This is an async server, so it's well suited to such tasks.
bad_user 14y ago
When you're talking about 25,000 real requests per second, I can assure you the web server and code are the bottleneck. And what are you trying to say exactly? That you don't need optimizations until you do? How's that in any way helpful?
shenedu 14y ago
Author here. > Add an endpoint with a poorly optimized SQL query: 20 concurrent connections. Agreed. http-kit use threadpool to compute the response, try to minimize this a little.
Legion 14y ago
> I find these benchmarks to not be very valuable. It's interesting to take one piece of the stack and see how much abuse it can take, even if it's not necessarily reflective of real world behavior.
- khet 14y ago
  I am afraid such out of context benchmarks will do more harm than good.
  - xt 14y ago
    I like what agentzh has done with lua + nginx. But his benchmarks are also showcasing how it works compared to other popular solutions. Check it out at http://agentzh.org/misc/slides/libdrizzle-lua-nginx.pdf http://agentzh.org/misc/slides/libdrizzle-lua-nginx.pdf
ed_blackburn 14y ago
Interesting as the article is, it's difficult to disagree re: database bottlenecks. Whilst the NoSql world is iterating away I wonder how much is going on behind the scenes at Oracle, Microsoft et al in regard to asynchronous sql. I guess it's a trade off between transactions and dirty reads?
alexkus 14y ago
They're valuable if the server is used to implement a COMET server. We maintain a large number of connections (doing overlapping long polling) and we send the same information to each connection (about 30 times an hour at peak). Even if the query to produce that data was poorly optimised it's only being performed once and then the results pushed out to every connection.
- shenedu 14y ago
  Yes. something like long polling do require server capable of maintaining many connections. http-kit provide `async-response` for this kind of usage: see http://http-kit.org http://http-kit.org for more detail. I am the author of http-kit, also one of the authors of delicious China: http://meiweisq.com http://meiweisq.com, trying to do some useful thing for our users (like realtime) with it. :)

tlrobinson 14y ago

In an asynchronous/event driven server slow SQL queries won't limit your concurrency, just latency. Memory consumption is what limits concurrency. CPU and bandwidth limits throughput. That said, I agree it's not a particularly useful benchmark.

fernandezpablo 14y ago
> In an asynchronous/event driven server slow SQL queries won't limit your concurrency Since this is on the JVM, SQL almost always means JDBC and JDBC is blocking so yes, SQL will in fact limit your concurrency.
- shenedu 14y ago
  yes, SQL is blocking, JVM also have threads. The http-kit is asynchronous(epoll on linux), the API for programmers is sync, which is more familiar.
- pygy_ 14y ago
  Alternatively, you can use a message queue or a REST service, and whatever lightweight, async database frontend.
  - fernandezpablo 14y ago
    That would just move the blocking code elsewhere, and now you have one extra framework / message queue on your stack (free complexity)
    - pygy_ 14y ago
      The point is to use a non-blocking DB frontend. Not necessarily JVM-based.

ptaoussanis 14y ago

Certainly your web server isn't likely to be the performance bottleneck in the majority of real-world applications. Even without a db call, just generating the response Clojure-side will kill your numbers (and Clojure is pretty darn fast). Still, the ability to cheaply handle large numbers of concurrent connections is great for things like WebSockets and long polling where you aren't crunching data for every connection all the time. This is an async server, so it's well suited to such tasks.

bad_user 14y ago

When you're talking about 25,000 real requests per second, I can assure you the web server and code are the bottleneck. And what are you trying to say exactly? That you don't need optimizations until you do? How's that in any way helpful?

shenedu 14y ago

Author here. > Add an endpoint with a poorly optimized SQL query: 20 concurrent connections. Agreed. http-kit use threadpool to compute the response, try to minimize this a little.

Legion 14y ago

> I find these benchmarks to not be very valuable. It's interesting to take one piece of the stack and see how much abuse it can take, even if it's not necessarily reflective of real world behavior.

khet 14y ago
I am afraid such out of context benchmarks will do more harm than good.
- xt 14y ago
  I like what agentzh has done with lua + nginx. But his benchmarks are also showcasing how it works compared to other popular solutions. Check it out at http://agentzh.org/misc/slides/libdrizzle-lua-nginx.pdf http://agentzh.org/misc/slides/libdrizzle-lua-nginx.pdf

ed_blackburn 14y ago

Interesting as the article is, it's difficult to disagree re: database bottlenecks. Whilst the NoSql world is iterating away I wonder how much is going on behind the scenes at Oracle, Microsoft et al in regard to asynchronous sql. I guess it's a trade off between transactions and dirty reads?

alexkus 14y ago

They're valuable if the server is used to implement a COMET server. We maintain a large number of connections (doing overlapping long polling) and we send the same information to each connection (about 30 times an hour at peak). Even if the query to produce that data was poorly optimised it's only being performed once and then the results pushed out to every connection.

shenedu 14y ago
Yes. something like long polling do require server capable of maintaining many connections. http-kit provide `async-response` for this kind of usage: see http://http-kit.org http://http-kit.org for more detail. I am the author of http-kit, also one of the authors of delicious China: http://meiweisq.com http://meiweisq.com, trying to do some useful thing for our users (like realtime) with it. :)