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

101–110 of 239 posts

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

#101

Post by jwdunne »

alex-lx wrote: post #91
shock-value wrote: post #53

Earlier quoted context omitted.

Another great option in Java is jOOQ, which lets you write type-safe and potentially composable queries such as: context .update(User.USER) .set(User.USER.NAME, userName) .where(User.USER.ID.eq(userId)) .execute()

jOOQ and its DSL is good, however IMO it's more readable using raw SQL (by using `context.fetchInto` and its variants) than to using DSL when deal with complex query.

I’ve noticed this in other contexts too.

For small queries with straight forward joins, a query builder is nice and readable.

But for larger, more complex queries, I found putting the query into its own file was best for readability.

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

#102

Post by huffmsa »

gchamonlive wrote: post #2

I have great experiences with Falcon for backend REST APIs, and it is supposed to be great in terms of requests per second. How does it compare to Sanic?

I'm a big Falcon user as well. Got into it because it was easier to get up and running without bells and whistles vs the more "popular" frameworks.

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

#103

Post by 0xkd »

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.

I disagree; not using ORMs isn't going to magically make developers write better queries, why not spend those few days training them to use the ORM better? Would you rather have raw SQL strewn about the codebase and have to worry about input validation and data (de)serialization every single place? Maybe it's ok for toy apps, but I wouldn't want developers bringing their own different styles of writing SQL all over a project. An ORM helps standardise this stuff

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

#104

Post by throwdbaaway »

Good article, but I can't help but notice a gaping hole in the benchmark -- why was there no attempt to run gunicorn in multi-threaded mode?

The article has a link to https://techspot.zzzeek.org/2015/02/15/asynchronous-python-a..., but failed to mention the key takeaway from the article:

> threaded code got the job done much faster than asyncio in every case

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

#105

Post by antihero »

morpheuskafka wrote: post #42
nmfisher wrote: post #30

Earlier quoted context omitted.

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.

I am by no means an experienced developer--but the issue I always seem to have without using an ORM is that there are string literals containing different bits of SQL scattered all throughout my code. In addition to being hard to refactor when the database model changes, I think there is a fairly high performance cost to doing so many string concatenations every time the code runs. Is there a better way to manage the…

I haven't done DB stuff in a while as I've mostly been frontend, but I reckon the way I'd lay it out is in the same way that I have a "clients" or "services" folder (or repo) which contains things that return Promise (and I don't have to care whether their source is HTTP, Firebase, or anything really). I would probably do the same with my back-end application (or lambda). Directories (or repo) full of services which are sets of high level calls (e.g. getPotatoes()) which are async functions that return data. Inside would be (probably) SQL.

> I think there is a fairly high performance cost to doing so many string concatenations every time the code runs

String concatenation is extremely cheap compared to any sort of IO or computation.

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

#106

Post by huffmsa »

kavalg wrote: post #94
cryptos wrote: post #58

Why Python at all? About 10 years ago I liked Python a lot (and still like it in principle) and felt very productive compared to, say, Java. Java was full of inconvenience, XML, bloated frameworks and all that. But today you can use Kotlin, that is in my opinion even nicer than Python, with performant frameworks (e. g. Quarkus or Ktor) on the super fast JVM. I don't want to start a language war, but maybe Python is n…

I can code comfortably in Python, Java, JavaScript and to some extent C/C++. In the last 4 years I have been using mostly Python for various reasons (Machine Learning, OS automation, web scraping ...). Compared to the other languages, Python feels lighter and faster to write to the extent that it rarely interrupts my flow of thoughts. Now and then I have to code in JavaScript (frontend), C/C++ (embedded / low level o…

I also notice I spend less time thinking "how do I do X in this language" with Python and just do it. Maybe not the best implementation of X, but that doesn't really matter because I implemented X, Y and Z while someone else got bogged down in their "better" language and barely got X across the finish line.

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

#107

Post by antihero »

jaimex2 wrote: post #15

When you start hitting bottlenecks in your python web framework its probably time to switch to a faster language, not another framework in python. You're probably done rapid prototyping by this point anyway.

Well if you convert everything from ORM to raw SQL, it will then be easier to extract all of that SQL and use it in a different web framework once you've measured and confirmed that your bottleneck is servicing requests in Python.

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

#108

Post by throwawayffffas »

forgotmypw17 wrote: post #95
Jonnax wrote: post #89

Earlier quoted context omitted.

The background is blue?

The background image is blue, the background itself is white. Without loading the image, the text is the same color.

I question the value of the comment of someone who loads css but not background images.

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

#109

Post by gchamonlive »

divbzero wrote: post #19
gchamonlive wrote: post #2

I have great experiences with Falcon for backend REST APIs, and it is supposed to be great in terms of requests per second. How does it compare to Sanic?

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

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

#110

Post by JulianWasTaken »

shock-value wrote: post #53
fn1 wrote: post #49

Earlier quoted context omitted.

In the java-world there are libraries like JDBI, which makes it possible to write interfaces with SQL-annotations and have serialization, connection setup etc. done for you: public interface UserDao { @SqlUpdate("CREATE TABLE user (id INTEGER PRIMARY KEY, name VARCHAR)") void createTable(); @SqlUpdate("INSERT INTO user(id, name) VALUES (?, ?)") void insertPositional(int id, String name); @SqlQuery("SELECT * FROM user…

Another great option in Java is jOOQ, which lets you write type-safe and potentially composable queries such as: context .update(User.USER) .set(User.USER.NAME, userName) .where(User.USER.ID.eq(userId)) .execute()

In Python this would look like sqlalchemy's query layer (which is great).
Post reply on HN