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

141–150 of 239 posts

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

#141

Post by exyi »

kaba0 wrote: post #123
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.

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

Like there wouldn't be anything in between /s

There are "simple ORMs" that only map results of SQL queries to objects. They do not provide a magic query API - which is the source of most problems. I don't do Python, but for .NET there is Dapper https://github.com/StackExchange/Dapper, you can have a look what I mean. You write the SQL query, explicitly execute it, the library maps the results of that query into objects (it's C#, so you have to declare the class. In Python I'd imagine it would create the object for you)

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

#142

Post by mlthoughts2018 »

7kmph wrote: post #41
mlthoughts2018 wrote: post #14

I think it’s been bog standard practice to run flask via uwsgi or gunicorn with async workers and use multiple process based workers per deployed server unit (eg per pod in Kubernetes). What matters is that the cumulative latency & throughput solve your problem, not how fast you can make one singular async worker thread. I figure most people running complex web services in production would just do an eye roll at this…

Could you share your company’s website?

No, I can’t speak on their behalf on Hacker News, so it is important to me to stay disconnected from my employer.

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

#143

Post by arcturus17 »

BiteCode_dev wrote: post #137
arcturus17 wrote: post #131

Earlier quoted context omitted.

I agree with your general take on developer productivity, but I don't feel that modern JS is significantly messier than Python, at least not to a level where it significantly impacts productivity (I'd rather avoid a debate on the abyssal depths of the language, eg, type coercion) I feel about the same amount of grievances with both. For instance I dislike Python's async and functional semantics ( list(map(lambda n...…

> list(map(lambda n... List comprehensions are much better for this. Functional doesn't mean you have to use a function call. If you can use the paradigm with literal syntax, just do so.

I never said functional means you necessarily have to use a function call, and I also understand list comprehensions are semantically functional, but sometimes you do need to use a function call.

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

#144

Post by girvo »

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.

Plain SQL with a “hydration” system to objects is quite powerful. DataMapper, I believe is the term of art?

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

#145

Post by jtdev »

bottled_poe wrote: post #138
lacksconfidence wrote: post #134

Earlier quoted context omitted.

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…

I’m sure there are valid engineering reasons to do it this way. One that comes to mind is memory footprint in allocating the objects associate with foreign key references.

Wow! Who would have thought that using an ORM would create so much uncertainty in a codebase.

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

#146

Post by jtdev »

zem wrote: post #25
divbzero wrote: post #17

Earlier quoted context omitted.

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

That’s a huge dependency to take on just for mapping and serializing, something that most languages provide in a standard library or base functionality of the language itself.

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

#147

Post by jtdev »

kaba0 wrote: post #118
lordnacho wrote: post #87

Earlier quoted context omitted.

IMO both are required. I'm lucky in that I did a lot of plain SQL early on, and found ORMs later, but I think ORMs do cut out a lot of time for quick-and-dirty queries that end up not being the bottleneck. The problem arises once you find a bottleneck, you won't know how to optimize it if you haven't done a bit of SQL mucking about earlier. Also, the big thing is you won't know how to translate to other ORMs if you d…

Yeah, ORMs are specifically made for insert-heavy operations or very basic mapping of rows to objects. Analytical queries and the rest should be done with SQL.

I keep seeing some variation of: “ORMs are really intended for x” or “ORMs work best when y is true”. At some point we should take an honest look to determine if ORMs provide enough benefit to justify their existence. “I can talk to the database without knowing SQL” doesn’t cut it.

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

#148

Post by Izkata »

mrslave wrote: post #77
bottled_poe wrote: post #67

Earlier quoted context omitted.

> 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. Hmm.. Sounds like a bug. Why is this not the same value for a foreign key?

It's not a bug, it is the same value . Only instead of using `first_table.foreign_id` to fetch the entire record from `second_table` only to use `second_table.id`, if you only need the identifier itself you already have it in `first_table`. A similar concept called covered queries exists whereby you index a table by foreign key, and a few additional columns that you do not expect to use in join conditions, but you do…

> It's not a bug, it is the same value.

Not necessarily, it can be overridden: "id" is only the default for models that haven't explicitly been given a field with the "primary_key" kwarg (common on legacy tables where the primary key column might for example be "user_id").

The alias guaranteed to be the same value is ".pk", and I'm not sure what django does if you try to create a column named "pk" that isn't the primary key.

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

#149

Post by kavalg »

arcturus17 wrote: post #131
kavalg wrote: post #94

Earlier quoted context omitted.

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 agree with your general take on developer productivity, but I don't feel that modern JS is significantly messier than Python, at least not to a level where it significantly impacts productivity (I'd rather avoid a debate on the abyssal depths of the language, eg, type coercion) I feel about the same amount of grievances with both. For instance I dislike Python's async and functional semantics ( list(map(lambda n...…

Thanks for the JS perspctive. Since my frontend work mostly involves hacking together prototypes and trying to integrate some JS libs in as quickly as possible, I guess I am kind of biased.

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

#150

Post by ehutch79 »

Izkata wrote: post #148
mrslave wrote: post #77

Earlier quoted context omitted.

It's not a bug, it is the same value . Only instead of using `first_table.foreign_id` to fetch the entire record from `second_table` only to use `second_table.id`, if you only need the identifier itself you already have it in `first_table`. A similar concept called covered queries exists whereby you index a table by foreign key, and a few additional columns that you do not expect to use in join conditions, but you do…

> It's not a bug, it is the same value. Not necessarily, it can be overridden: "id" is only the default for models that haven't explicitly been given a field with the "primary_key" kwarg (common on legacy tables where the primary key column might for example be "user_id"). The alias guaranteed to be the same value is ".pk", and I'm not sure what django does if you try to create a column named "pk" that isn't the prim…

If your tables don't use id, or are doing something strange, YOU wrote that code. You should know it's going to be a thing you need to deal with, because YOU did something unusual.
Post reply on HN