5 ms·

The error(?) in this benchmark is putting the DB on the same machine as the server. Async solves the problem of not wanting to block other requests while you g

The error(?) in this benchmark is putting the DB on the same machine as the server. Async solves the problem of not wanting to block other requests while you go out to expensive external resources. If you benchmark stuff while it's all on the same machine, it masks that cost. I couldn't find the size of the DB. Is it 100GB of data? or more like 10MB? Doing one point query on 10MB might not touch even disk a whole lot. If you were using srcreigh's hosted DB service and queries took 1s to run, the sync servers throughput would suffer greatly, meanwhile async servers would still perform pretty good.

tempest_ 5y ago
This was what I noticed as well. The minute your db queries become expensive the sync workers end up slowing down and stopping other functions. If your workers are tied up doing expensive queries you might be holding up cheap queries that might be getting data from a cache or whatever.
oefrha 5y ago
> If you were using srcreigh's hosted DB service and queries took 1s to run, your sync server latency would be ~1s :) Or longer if they get queued up. Yep, and your 16-worker gunicorn is going to serve 16 rps. What's shown here (nginx, pg, Python application running on the same low CPU VPS, one extremely fast db query per request) is not a "realistic benchmark".
stickyricky 5y ago
If you're at the point where you've got a single application server with 100 waiting connections on a database, you've already blundered. Firstly, you're either overpaying for your database (connections aren't free) or you're underpaying for application servers. Fixing the problem in either dimension reduces the utility of your async server. There's also this myth that Python code is free if the i/o wait is long enough. That's not true. 1). 100 queued connections on an async python server sucks so much momentum out your application. Especially in a resource constrained cloud environment. 2). Any server awaiting a database is going to transform the data to some response object which is going to wreck your overloaded async server. 3). As far as I know, all the async WSGIs are written in Python and will use WAY more CPU than the C-based sync WSGIs.
- tempest_ 5y ago
  Don't get too hung up on this toy example being a database. The bottle neck could be any form of downstream service, possibly one you do not control. Not everything is a CRUD app running in the cloud.
  - stickyricky 5y ago
    It does not matter if you describe a service as a database or anything else. The implications are the same. A service must make architectural decisions. Those decisions impose limits. And those limits are billed. Regardless, HTTP servers are completely uninteresting on their own. No one makes a request to a web server to see how the server is feeling. The server's only function is to serve content. Content it must retrieve (i/o), store (memory), and transform (cpu). That store and transform step nukes your RPS and is completely unavoidable. And, in a high worker environment, will crash your system.
    - srcreigh 5y ago
      What if your HTTP server is clock-as-a-service? Then you'd waiting for an unlimited, free external resource called "time".
      - stickyricky 5y ago
        > If my Grandmother had wheels she would have been a bike[1]. 1. https://www.youtube.com/watch?v=A-RfHC91Ewc https://www.youtube.com/watch?v=A-RfHC91Ewc On a more serious note, describe the service for me and I'll give an opinion. Clock as a service is not specific enough.
        deleted 5y ago
        [deleted]
        srcreigh 5y ago
        It's plenty specific. I give you X: float, you return after X seconds.
romero-jk 5y ago
No, in his benchmarks the async version should still be faster, the problem is python is just slow.
SavantIdiot 5y ago
I'm kinda surprised given the huge amount of effort the person put into this study that the seemed to overlook the key point of async/await patterns: latency. Also: how did we come to Python as a web server when there are languages and applications better suited? Do we really want one language to be everything to everyone?
- jjice 5y ago
  Because people like Python and it does a decent job at it. Might not be your cup of tea for a variety of reasons, but a lot of people think it works well on the server. Is speed the concern? Spinning up a new server is pretty easy nowadays. Is it the lack of static typing? Aside from type hint support over the last few versions, I'd claim based on experience that PHP feels more loose with its types than Python is (mixed return results feel more common in PHP). Python does a lot well for a lot of people. All that said, I think a lot of languages can do a lot of things well without serious performance impact. If you need the performance, choose the language based on that criteria.
  - SavantIdiot 5y ago
    > Python does a lot well for a lot of people. That's why I use PERL for my web server. ;) I'm not denying Python is an amazing language. I have to use it for machine learning, and I've grown to really like it since the first time I used it in the 90's. Just seems odd. Like, if you had a catering business and you drove a Ford Escort, and decided to add a bunch of trailers to it because it had too little capacity in the back seat. And then tried to optimizes those trailers because it was too inefficient, rather than just buying a delivery truck suited for delivering food. OK, that was an awkward analogy.
    - markoman 5y ago
      I'm a Perl guy too. May I ask what Perl technology you're using? Dancer perhaps?
      - 5y ago
remram 5y ago
Is it even using an async DB connector?

tempest_ 5y ago

This was what I noticed as well. The minute your db queries become expensive the sync workers end up slowing down and stopping other functions. If your workers are tied up doing expensive queries you might be holding up cheap queries that might be getting data from a cache or whatever.

oefrha 5y ago

> If you were using srcreigh's hosted DB service and queries took 1s to run, your sync server latency would be ~1s :) Or longer if they get queued up. Yep, and your 16-worker gunicorn is going to serve 16 rps. What's shown here (nginx, pg, Python application running on the same low CPU VPS, one extremely fast db query per request) is not a "realistic benchmark".

stickyricky 5y ago

If you're at the point where you've got a single application server with 100 waiting connections on a database, you've already blundered. Firstly, you're either overpaying for your database (connections aren't free) or you're underpaying for application servers. Fixing the problem in either dimension reduces the utility of your async server. There's also this myth that Python code is free if the i/o wait is long enough. That's not true. 1). 100 queued connections on an async python server sucks so much momentum out your application. Especially in a resource constrained cloud environment. 2). Any server awaiting a database is going to transform the data to some response object which is going to wreck your overloaded async server. 3). As far as I know, all the async WSGIs are written in Python and will use WAY more CPU than the C-based sync WSGIs.

tempest_ 5y ago
Don't get too hung up on this toy example being a database. The bottle neck could be any form of downstream service, possibly one you do not control. Not everything is a CRUD app running in the cloud.
- stickyricky 5y ago
  It does not matter if you describe a service as a database or anything else. The implications are the same. A service must make architectural decisions. Those decisions impose limits. And those limits are billed. Regardless, HTTP servers are completely uninteresting on their own. No one makes a request to a web server to see how the server is feeling. The server's only function is to serve content. Content it must retrieve (i/o), store (memory), and transform (cpu). That store and transform step nukes your RPS and is completely unavoidable. And, in a high worker environment, will crash your system.
  - srcreigh 5y ago
    What if your HTTP server is clock-as-a-service? Then you'd waiting for an unlimited, free external resource called "time".
    - stickyricky 5y ago
      > If my Grandmother had wheels she would have been a bike[1]. 1. https://www.youtube.com/watch?v=A-RfHC91Ewc https://www.youtube.com/watch?v=A-RfHC91Ewc On a more serious note, describe the service for me and I'll give an opinion. Clock as a service is not specific enough.
      - deleted 5y ago
        [deleted]
      - srcreigh 5y ago
        It's plenty specific. I give you X: float, you return after X seconds.

romero-jk 5y ago

No, in his benchmarks the async version should still be faster, the problem is python is just slow.

SavantIdiot 5y ago

I'm kinda surprised given the huge amount of effort the person put into this study that the seemed to overlook the key point of async/await patterns: latency. Also: how did we come to Python as a web server when there are languages and applications better suited? Do we really want one language to be everything to everyone?

jjice 5y ago
Because people like Python and it does a decent job at it. Might not be your cup of tea for a variety of reasons, but a lot of people think it works well on the server. Is speed the concern? Spinning up a new server is pretty easy nowadays. Is it the lack of static typing? Aside from type hint support over the last few versions, I'd claim based on experience that PHP feels more loose with its types than Python is (mixed return results feel more common in PHP). Python does a lot well for a lot of people. All that said, I think a lot of languages can do a lot of things well without serious performance impact. If you need the performance, choose the language based on that criteria.
- SavantIdiot 5y ago
  > Python does a lot well for a lot of people. That's why I use PERL for my web server. ;) I'm not denying Python is an amazing language. I have to use it for machine learning, and I've grown to really like it since the first time I used it in the 90's. Just seems odd. Like, if you had a catering business and you drove a Ford Escort, and decided to add a bunch of trailers to it because it had too little capacity in the back seat. And then tried to optimizes those trailers because it was too inefficient, rather than just buying a delivery truck suited for delivering food. OK, that was an awkward analogy.
  - markoman 5y ago
    I'm a Perl guy too. May I ask what Perl technology you're using? Dancer perhaps?
    - 5y ago

remram 5y ago

Is it even using an async DB connector?