Hacker News Reader

Comment by srcreigh | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

What if your HTTP server is clock-as-a-service? Then you'd waiting for an unlimited, free external resource called "time".

> If my Grandmother had wheels she would have been a bike[1].

1. 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.

It's plenty specific. I give you X: float, you return after X seconds.

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?

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.

> 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.

I'm a Perl guy too. May I ask what Perl technology you're using? Dancer perhaps?

I'm not, I was being lighthearted. Sorry, bad joke I guess.

But to the other poster's point, some people use what is natural: PERL is so absolutely burned into my brain after 10 years writing CAD flows with it, that when I need to munge a file I've already written the code in my head before I've even opened my text editor.

> 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".

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

Is it even using an async DB connector?

Reply on news.ycombinator.com