4 ms·

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 eithe

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.

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.