Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

12 requests per second: A realistic look at Python web frameworks

suade.org

Post reply on HN
Print view View original

21–30 of 239 posts

Re: 12 requests per second: A realistic look at Python web frameworks

#21

Post by chmod775 »

Jarred wrote: post #6
est wrote: post #3

Might as well refer to TechEmpower benchmarks. https://www.techempower.com/benchmarks/

just.js (#9) looks interesting https://github.com/just-js/just It seems to be a much tinier JavaScript runtime than Node.js (still using v8), but linux only The benchmark is probably unrealistically optimized code but even so, it implies Node.js itself has a large performance overhead

If you're not paying attention it would look that way, yes.

If you pay attention you'll notice that just.js is using postgres as their DB, while all of the node benchmarks are handicapped by either using mongoose/mongodb or MySQL.

There is no node benchmark with postgres, but all of the fastest benchmarks used it.

"lithium" is a good example to show how much of an impact switching to postgres has. All of the 4 lithium benchmarks are identical except in what DB they use.

The results are: lithium-postgres-batch (#2 - 659850), lithium-postgres-beta (#13 - 398773), lithium-postgres (#14 - 398258), lithium (#45 - 271989). The last result is MySQL.

Re: 12 requests per second: A realistic look at Python web frameworks

#22

Post by notafraudster »

kijin wrote: post #9
Laminary wrote: post #4

In my benchmark testing, SSL appears to be the bottleneck; e.g., Apache vs. Nginx does not really matter. I assume the benchmarks above 10,000 RPS are not using SSL and regular HTTP? How are people doing benchmarks at 10k-100k RPS?

HTTP/1.1 Keep-Alive helps a lot. HTTP/2 is even better. You only do the SSL handshake once.

Flipping the HTTP/2 switch was amazing for me -- I have a page that for reasons needs to load ~500 small images. Initially I was worried about having to figure out a sprite-based method to compile the images (which is not ideal because there are many permutations of which 500 images), but when I turned on HTTP/2, the overhead just disappeared. The images load instantly. I'm nowhere near the multi-k RPS metrics as above, but it was night and day for me even for individual requests.

Re: 12 requests per second: A realistic look at Python web frameworks

#23

Post by vosper »

ramraj07 wrote: post #5

Don't forget that you're paying a huge price using the sqlalchemy orm - https://docs.sqlalchemy.org/en/13/faq/performance.html If I know an endpoint is going to be hit hard, I forgo trying to use the ORM (except to maybe get the table name from the model obj so some soul can trace it's usage here in the future) and directly do an engine.execute( ). Makes a huge difference. Next optimization I do is create stored proc…

You can also use SQLAlchemy Core, which is an intermediate between the full-blown ORM and running actual strings of SQL. I've had a great experience with Core - I can easily have it output essentially the exact SQL I'd write by hand, but I get many benefits (like the ability to compose queries) that are nicer than dealing with raw SQL.

Re: 12 requests per second: A realistic look at Python web frameworks

#24

Post by solox3 »

Izkata wrote: post #16
imperio59 wrote: post #10

My experience doing perf optimizations in real world systems with many many people writing code to the same app is a lot of inefficiencies happen due to over fetching data, inefficiencies caused by naively using the ORM without understanding the underlying cost of the query, and lack of actual profiling to find where the actual bottlenecks are (usually people writing dumb code without realizing it's expensive). Sure,…

> (usually people writing dumb code without realizing it's expensive) Some years ago, one morning I gave a co-worker a recommendation on how to improve a loop that was unnecessarily hitting database through the Django ORM. He committed the fix that afternoon. Barely an hour later I accidentally reintroduced the exact same slowdown in the exact same loop when adding a different piece of data to it. Soooo yeah, ORMs ca…

Something about select_related? Please do share.

Re: 12 requests per second: A realistic look at Python web frameworks

#25

Post by zem »

divbzero wrote: post #17
imperio59 wrote: post #10

My experience doing perf optimizations in real world systems with many many people writing code to the same app is a lot of inefficiencies happen due to over fetching data, inefficiencies caused by naively using the ORM without understanding the underlying cost of the query, and lack of actual profiling to find where the actual bottlenecks are (usually people writing dumb code without realizing it's expensive). Sure,…

I increasingly lean towards plain SQL over ORMs. It requires greater familiarity with SQL but I prefer that over greater familiarity with ORM-specific syntax that doesn’t translate across frameworks or languages. In addition, you can prototype new queries and profile existing queries in the database and copy-paste directly into your code.

for me the value of an ORM is not so much query synthesis as serialisation of object fields to db columns and vice versa

Re: 12 requests per second: A realistic look at Python web frameworks

#26

Post by reasonabl_human »

chmod775 wrote: post #21
Jarred wrote: post #6

Earlier quoted context omitted.

just.js (#9) looks interesting https://github.com/just-js/just It seems to be a much tinier JavaScript runtime than Node.js (still using v8), but linux only The benchmark is probably unrealistically optimized code but even so, it implies Node.js itself has a large performance overhead

If you're not paying attention it would look that way, yes. If you pay attention you'll notice that just.js is using postgres as their DB, while all of the node benchmarks are handicapped by either using mongoose/mongodb or MySQL. There is no node benchmark with postgres, but all of the fastest benchmarks used it. "lithium" is a good example to show how much of an impact switching to postgres has. All of the 4 lithiu…

What makes postgres special in these cases?

Re: 12 requests per second: A realistic look at Python web frameworks

#27

Post by DangitBobby »

solox3 wrote: post #24
Izkata wrote: post #16

Earlier quoted context omitted.

> (usually people writing dumb code without realizing it's expensive) Some years ago, one morning I gave a co-worker a recommendation on how to improve a loop that was unnecessarily hitting database through the Django ORM. He committed the fix that afternoon. Barely an hour later I accidentally reintroduced the exact same slowdown in the exact same loop when adding a different piece of data to it. Soooo yeah, ORMs ca…

Something about select_related? Please do share.

My guess is accessing a related field within a loop causing a database request per iteration, e.g.

``` [book.author.name for book in Book.objects.all()] ```

Re: 12 requests per second: A realistic look at Python web frameworks

#28

Post by zerd »

chmod775 wrote: post #21
Jarred wrote: post #6

Earlier quoted context omitted.

just.js (#9) looks interesting https://github.com/just-js/just It seems to be a much tinier JavaScript runtime than Node.js (still using v8), but linux only The benchmark is probably unrealistically optimized code but even so, it implies Node.js itself has a large performance overhead

If you're not paying attention it would look that way, yes. If you pay attention you'll notice that just.js is using postgres as their DB, while all of the node benchmarks are handicapped by either using mongoose/mongodb or MySQL. There is no node benchmark with postgres, but all of the fastest benchmarks used it. "lithium" is a good example to show how much of an impact switching to postgres has. All of the 4 lithiu…

Somehow just.js is faster than Rust and C++ in 20-queries benchmark, they're all using postgres. https://www.techempower.com/benchmarks/#section=data-r20&hw=...

Re: 12 requests per second: A realistic look at Python web frameworks

#30

Post by nmfisher »

tnash wrote: post #7

Use of ORMs is often a performance choke point. Raw DB queries are often much, much faster. Almost always, the more you abstract, the worse you perform. It's great as a developer but not so great as a user.

I haven't touched an ORM in over 6 years, but unless they've improved since then, I honestly can't think of a single reason why anyone would choose to use one.

They're clunky monstrosities that act only as guard-rails for inexperienced developers. Far better to invest a few days (which is realistically all you need) to improve their SQL skills and/or code-review practices.

Post reply on HN