3 ms·

This is quite interesting, but I don't find req/sec very interesting at all. These should be about matters of concurrency, that is, how much is being done at on

by windlep 10y ago

This is quite interesting, but I don't find req/sec very interesting at all. These should be about matters of concurrency, that is, how much is being done at once, not how many req/sec overall are done (which could almost be explained away purely by the gains in lower latency). These benchmarks seem to only use 10 clients concurrently, max. That's ridiculously low. A few questions I'd like to see answered. How many clients can you connect to each server, and have each one ping once per 5 mins, before the CPU gets overloaded? How much memory is used per connection? How does PyPy+Twisted fair in this?

1st1 10y ago
> These benchmarks seem to only use 10 clients concurrently, max. That's ridiculously low. I've just update the post with more details on HTTP benchmarks and attached the correct full-results file [1]. The concurrency level for HTTP benchmarks is 300, not 10. To answer other questions, I'll have to run some benchmarks tomorrow :) [1] http://magic.io/blog/uvloop-blazing-fast-python-networking/http-bench.html http://magic.io/blog/uvloop-blazing-fast-python-networking/h...
- windlep 10y ago
  Cool! For the client test I'm referring to, these would be long-lived clients that stay around and just TCP ping for an echo server, rather than HTTP calls that connect/disconnect. In my experience, PyPy+twisted is around 5-25x faster CPython/twisted, and smoked asyncio as well. Would be great to see how uvloop compares there, and of course, someday when PyPy supports Python 3.5, there's no reason it couldn't use uvloop via cffi I'd hope.
  - 1st1 10y ago
    > [..] Would be great to see how uvloop compares there [..] Yep, I'm curious to see what will happen there. Do you have any suggestions on what tool to use to generate the load? > [..] someday when PyPy supports Python 3.5, there's no reason it couldn't use uvloop via cffi I'd hope. We'll figure that out! ;)
    - windlep 10y ago
      I wrote a tool to evaluate memory per connection one layer up (at websocket level), using autobahn. It works in asyncio, so it should work fine with uvloop. https://github.com/bbangert/ssl-ram-testing/ https://github.com/bbangert/ssl-ram-testing/

by windlep 10y ago

1st1 10y ago

> These benchmarks seem to only use 10 clients concurrently, max. That's ridiculously low. I've just update the post with more details on HTTP benchmarks and attached the correct full-results file [1]. The concurrency level for HTTP benchmarks is 300, not 10. To answer other questions, I'll have to run some benchmarks tomorrow :) [1] http://magic.io/blog/uvloop-blazing-fast-python-networking/http-bench.html http://magic.io/blog/uvloop-blazing-fast-python-networking/h...

windlep 10y ago
Cool! For the client test I'm referring to, these would be long-lived clients that stay around and just TCP ping for an echo server, rather than HTTP calls that connect/disconnect. In my experience, PyPy+twisted is around 5-25x faster CPython/twisted, and smoked asyncio as well. Would be great to see how uvloop compares there, and of course, someday when PyPy supports Python 3.5, there's no reason it couldn't use uvloop via cffi I'd hope.
- 1st1 10y ago
  > [..] Would be great to see how uvloop compares there [..] Yep, I'm curious to see what will happen there. Do you have any suggestions on what tool to use to generate the load? > [..] someday when PyPy supports Python 3.5, there's no reason it couldn't use uvloop via cffi I'd hope. We'll figure that out! ;)
  - windlep 10y ago
    I wrote a tool to evaluate memory per connection one layer up (at websocket level), using autobahn. It works in asyncio, so it should work fine with uvloop. https://github.com/bbangert/ssl-ram-testing/ https://github.com/bbangert/ssl-ram-testing/