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

121–130 of 239 posts

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

#121

Post by rglullis »

Hamuko wrote: post #115
rglullis wrote: post #76

Earlier quoted context omitted.

Because when you are acessing .user you are asking for all its properties, not just the id. Django does provide relatively easy ways to get over the N+1 issue, though. If you do Book.objects.select_related('user'), only one query is made.

`QuerySet.select_related()` and `QuerySet.prefetch_related()` are the bread and butter of Django query optimisation. I think most of the time that I've noticed a performance issue in our code, it's been easily fixed with one of those.

Django's ORM gets a lot of flak, but I don't remember the last time I had complex queries that I could not do with it.

You still need to understand a minimum of SQL and databases, and usually those that complain about the ORM are the ones that expect it to be a "sufficiently advanced compiler", but it has matured so much that nowadays the developers consider a *bug* every time the answer to How do I do this query X? involves something along the lines of use .extra or raw sql.

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

#122

Post by m12k »

lacksconfidence wrote: post #114
m12k wrote: post #80

Earlier quoted context omitted.

Well, it is the same value, but the ORM doesn't handle book.user.id any differently than it does book.user.name where it isn't the same value, and thus the only option is to fetch the second table. So it's not a bug, it's really just the ORM being consistent in how it handles queries, thus missing out on a possible optimization in this special case, where a simpler query could have given the same result.

No, that is clearly a bug. The ORM already has the value of book.id, that's how it knows how to fetch the right book. Performing extra queries is just poor implementation.

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 whether all of it will be needed or not, because Python is not a compiled language, so there's no way to tell in advance when executing the book.user.id query that no further fields of .user will be needed, so it shouldn't actually do what it's been asked to do, to fetch the entire object, but rather only fetch .id which is available in a different way, so the whole query can be skipped. So yes, this is suboptimal usage, but only the programmer can know that, so it falls to them to optimize if they want to.

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

#123

Post by kaba0 »

nmfisher wrote: post #30
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.

Yes, things like setString(1, “asd”) and conversely getInt(2) are so beautiful and will never introduce mistakes /s

ORMs are there for mapping objects and well, relations. Most ORMs provide additional features, but at the core they can, and for more complicated queries they should be used with native SQL queries. They are made for OLTP not for OLAP

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

#124

Post by arcturus17 »

nodamage wrote: post #86
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#.

That 7 million requests per second is achieved by writing a hard coded plain text HTTP response string directly to the client... it is so far disconnected from any real world use case that the number is basically meaningless.

It's still 8th in the composite benchmark. And the criticism you're leveling would affect the entire benchmark design, rather than a particular framework score, no?

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

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

#125

Post by arcturus17 »

qw wrote: post #92
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#.

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 ranks 8 in the composite (which adds a layer of human opinion, since they weigh each of the benchmarks...)

Java and Rust are both above, but my takeaway is that it seems to be by far the best-performing batteries-included framework according to the benchmark. It leaves the likes of Rails, Laravel, Django, Phoenix, Spring or Nest.js in the dust.

Is there something in the benchmark that favors .net core above all the others?

I'm genuinely asking, I've never even tried .net but I like full-batteries frameworks and this catches my attention.

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

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

#128

Post by arcturus17 »

EvilEy3 wrote: post #97
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#.

Go being low-level has nothing to do with performance. They deliberately keep feature set on this level, they're not making some kind of trade-off. Also, high performance C# is so low level that you might as well write C++. Or you think you will use EF, LINQ and have 7 millions rps?

> Or you think you will use EF, LINQ and have 7 millions rps?

I'm imagining not, but it's still comparatively faster than most, if not all, "full-batteries frameworks", right?

I'm assuming the use of ORMs and such is more or less uniform in the comparison (eg, if they don't use EF for .net, they don't use Django ORM either)

The overall performance of .net across these benchmarks really catches my attention like it does GP...

I'm looking for a full-batteries framework based on a strongly typed language and never in my life I thought I'd say this, but it might be time to give .net / C# a whirl?

I've heard really good things about the dev experience from people here on HN, F# is a really cool bonus, and the fact that it looks at least comparatively performant could be the icing on the cake.

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

#129

Post by rglullis »

DangitBobby wrote: post #27
solox3 wrote: post #24

Earlier quoted context omitted.

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()] ```

Maybe I spent too much time with Django already, but if I see anyone doing anything but Book.objects.values_list('author__name', flat=True) for this type of expression, I would mark it as a 3x WTF? in the code review.
Post reply on HN