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

Post by hangtwenty » Fri, Feb 19, 2021, 3:39 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…

Post by rglullis » Fri, Feb 19, 2021, 4:07 PM UTC

lacksconfidence wrote: post #134

m12k wrote: post #122

Earlier quoted context omitted.

The programmer also already had the value in book.user_id but still chose to ask the ORM to fetch all of .user so they could get .id from there instead. And they might then afterward call .name on it as well, and there would be no further queries, because the ORM has already been asked to fetch all fields of .user - so it might in fact have been sensible to fetch all of .user if so. The query builder cannot know whet…

Perhaps i'm a bit odd, but when I'm going to lean on an ORM to do things I expect it to actually do them. I expect that foo.user_id does not exist, because that representation has been transformed into an object. foo.user.id should be the only viable reference to the id. foo.user.id should return the value it already knows, any other property access i would expect will do the equiv of `select * from ...` if the objec…

Post by hu3 » Fri, Feb 19, 2021, 4:13 PM UTC

Ambix wrote: post #167

Why is it so? I've got 100K requests per sec with PHP easily [1] [1] https://github.com/gotzmann/comet

Post by airstrike » Fri, Feb 19, 2021, 4:20 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…

Post by infensus » Fri, Feb 19, 2021, 4:22 PM UTC

nodamage wrote: post #116

qw wrote: post #92

Earlier quoted context omitted.

C# is only at number 3 in your list. Both Java and Rust are above it in the list. It's also a very "artificial" benchmark and real world code will give different results (if you have static content, just put it in a CDN and don't worry) Other benchmarks from the same site: - JSON Serialization: C# is number 34 - Single query: C# is number 23 - Fortunes: C# is number 7

It needs to be emphasized how artificial these benchmarks really are. Here is the source for the Fortunes C# benchmark: https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... There's no routing or templating, it just writes a bunch of strings. No one would build an actual web app this way. The only C# benchmarks that are remotely realistic are the mvc variants, starting with aspcore-mvc-ado-pg at number 79.