12 requests per second: A realistic look at Python web frameworks • Hacker News Board

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

#181

Post by jordic » Fri, Feb 19, 2021, 4:28 PM UTC

polyrand wrote: post #140

Related to ORMs/queries/performance, I have found the following combination really good: * aiosql[0] to write raw SQL queries and having them available as python functions (discussed in [1]) * asyncpg[2] if you are using Postgres * Map asyncpg/aiosql results to Pydantic[3] models * FastAPI[4] Pydantic models become the "source of truth" inside the app, they are designed as a copy of the DB schema, then functions rece…

We do something like this, also we took some inspiration from hashura. Asyncpg it's so fast an ergonomic.

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

#182

Post by Ambix » Fri, Feb 19, 2021, 4:29 PM UTC

hgretg3443 wrote: post #65

C#/ASP.NET is the fastest web framework now: https://www.techempower.com/benchmarks/#section=test&runid=8... 7.000.000 requests per second Even GO can only achieve 4.500.000 million requests per secnod being a low-level language, in opposite to high-level C#.

Why do enyone needs framework to print zillion Hello Worlds to the client?

It's more interesting to see results of high-load DB tests, for example:

https://www.techempower.com/benchmarks/#section=data-r20&hw=...

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

#183

Post by pantsforbirds » Fri, Feb 19, 2021, 4:31 PM UTC

polyrand wrote: post #140

Related to ORMs/queries/performance, I have found the following combination really good: * aiosql[0] to write raw SQL queries and having them available as python functions (discussed in [1]) * asyncpg[2] if you are using Postgres * Map asyncpg/aiosql results to Pydantic[3] models * FastAPI[4] Pydantic models become the "source of truth" inside the app, they are designed as a copy of the DB schema, then functions rece…

The asyncpg library is honestly incredible. I wrote a backfill script that would: 1. dump the rows of a postgres table matching a query (usually a range on the index with a filter or two on other columns) 2. Do some very basic transformation on the rows (few replaces with small regex) 3. Take each transformed row and dump into a rabbitmq queue.

I was using aio-pika for the rabbit queue and asyncpg and was getting a consistent 25k messages/sec for like 200 lines of code.

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

#184

Post by fhood » Fri, Feb 19, 2021, 4:33 PM UTC

gregmac wrote: post #162

stevenjohns wrote: post #39

Earlier quoted context omitted.

There is lots of truth to this. Some ORMs like Django perform joins in very unsuspecting ways. A simple example is, say, foreign keys. Trying to access the foreign key of an object by doing `book.user.id` does an additional query for the user table to get the ID. It's less known that the id is immediately available by just doing `book.user_id` instead. I've spent time optimising things like text searches down from 20…

The most insidious part about misusing ORMs is it's often not visible for a while. Modern DBMSs on modern hardware are crazy fast , so when you have only a few tens or hundreds of thousand rows in your table, those inefficient and pointless ORM queries are just not noticeable because you still get sub-second response times. As your database grows, the site begins to gets slower and slower, but it's hard to distinguis…

We have everything hooked into lightstep. Makes it extremely easy to track down problematic operations.

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

#185

Post by bcrosby95 » Fri, Feb 19, 2021, 4:40 PM UTC

stevenjohns wrote: post #39

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,…

There is lots of truth to this. Some ORMs like Django perform joins in very unsuspecting ways. A simple example is, say, foreign keys. Trying to access the foreign key of an object by doing `book.user.id` does an additional query for the user table to get the ID. It's less known that the id is immediately available by just doing `book.user_id` instead. I've spent time optimising things like text searches down from 20…

If you're selecting tons of data when you SELECT * you might also have a god object. I prefer to have my model be a bit more split up by use rather than being full of random stuff. E.g. a customer_address table rather than stuffing all that data into customer, even if they only have a single address.

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

#186

Post by fokinsean » Fri, Feb 19, 2021, 4:41 PM UTC

polyrand wrote: post #140

Related to ORMs/queries/performance, I have found the following combination really good: * aiosql[0] to write raw SQL queries and having them available as python functions (discussed in [1]) * asyncpg[2] if you are using Postgres * Map asyncpg/aiosql results to Pydantic[3] models * FastAPI[4] Pydantic models become the "source of truth" inside the app, they are designed as a copy of the DB schema, then functions rece…

This sounds like a really cool stack. I'm testing the waters with FastAPI and SQLAlchemy right now, but SQLAlchmey feels like it just gets in the way.

Do you have an example project which uses all of these I could look at?

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

#187

Post by divbzero » Fri, Feb 19, 2021, 4:42 PM UTC

gchamonlive wrote: post #109

divbzero wrote: post #19

Earlier quoted context omitted.

> I have great experiences with Falcon Then keep using Falcon! OP’s core thesis is that developer comfort matters more when choosing an API framework because the performance bottleneck is usually found elsewhere. The API itself should be fast enough with some combination of Gunicorn, gevent, PyPy, and horizontal scaling.

I just wanted to know how it would compare with Sanic, because I never used it.

The biggest difference is that Falcon is synchronous while Sanic is asynchronous. With Sanic, you would explicitly specify async/await for asynchronous operations and use asynchronous libraries for I/O. Switching to Sanic could also affect how you deploy to production. Both are plenty fast.

FastAPI [1] is also worth considering if you’re looking into asynchronous API frameworks. It comes with nice features for specifying API schemas.

[1]: https://fastapi.tiangolo.com/

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

#188

Post by vp8989 » Fri, Feb 19, 2021, 4:47 PM UTC

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,…

"Focus on making a product people wanna actually use first. If you're lucky enough to get to scale you can work about optimizing it then."

This seems like a false dichotomy. Avoiding obvious performance mistakes such as the ones you mentioned does not require additional focus that would detract from general building. It just requires that you know what you are doing.

If you are the type of person who makes said mistakes, its unlikely you would ever go back and fix them by "focusing" on performance because the issue is simply that you don't know what you don't know. Likely someone else will come along in future and point out your mistakes to you.

Optimization that actually hinders you from building and requires focus is at the very margins and almost no one is going to those levels in typical "application" code.

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

#189

Post by luord » Fri, Feb 19, 2021, 4:54 PM UTC

And here I was living under the assumption that psycopg2 was the only option, and probably the biggest reason I was not using pypy. Gotta take a look at pg8000.

In general, I've always liked the idea of pypy, so I'll try to use it more, and not just for performance. Will also donate when I can.

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

#190

Post by pantsforbirds » Fri, Feb 19, 2021, 5:00 PM UTC

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 honestly would rather just read a SQL query. Almost every developer is familiar with SQL so you can immediately know what is happening vs if you are looking at a code base with an ORM you're not familiar with.