Re: Why so fast a web framework?

[Benjamin Schollnick]

>> Sometimes this group reminds me of a certain large company I worked for.
>> If they didn't have a solution addressing a problem, they'd pretend it
>> didn't matter and belittle anyone who questioned that version of reality.
>> 
> 
> That's not strictly true; what's happening here is that someone's
> published a cool-looking bar graph but nobody knows what it really
> means. I don't feel the need to delve into everyone's benchmarks to
> explain why Python is purportedly worse. If someone uses those kinds
> of numbers to decide which programming language to use, they have
> bigger problems.

If you dig a bit, the benchmark is scary…
As in stupid-scary.

It consists of, 7 tests, and then a composite score is generated:

JSON Serialization - In this test, each response is a JSON serialization of a 
freshly-instantiated object that maps the key message to the value Hello, World!
Single Query - In this test, each request is processed by fetching a single row 
from a simple database table. That row is then serialized as a JSON response.
Multiple Queries - In this test, each request is processed by fetching multiple 
rows from a simple database table and serializing these rows as a JSON 
response. The test is run multiple times: testing 1, 5, 10, 15, and 20 queries 
per request. All tests are run at 512 concurrency.
Cached Queries - In this test, each request is processed by fetching multiple 
cached objects from an in-memory database (the cache having been populated from 
a database table either as needed or prior to testing) and serializing these 
objects as a JSON response. The test is run multiple times: testing 1, 5, 10, 
15, and 20 cached object fetches per request. All tests are run at 512 
concurrency. Conceptually, this is similar to the multiple-queries test except 
that it uses a caching layer.
Fortunes - In this test, the framework's ORM is used to fetch all rows from a 
database table containing an unknown number of Unix fortune cookie messages 
(the table has 12 rows, but the code cannot have foreknowledge of the table's 
size). An additional fortune cookie message is inserted into the list at 
runtime and then the list is sorted by the message text. Finally, the list is 
delivered to the client using a server-side HTML template. The message text 
must be considered untrusted and properly escaped and the UTF-8 fortune 
messages must be rendered properly.  Whitespace is optional and may comply with 
the framework's best practices.
data Updates - This test exercises database writes. Each request is processed 
by fetching multiple rows from a simple database table, converting the rows to 
in-memory objects, modifying one attribute of each object in memory, updating 
each associated row in the database individually, and then serializing the list 
of objects as a JSON response. The test is run multiple times: testing 1, 5, 
10, 15, and 20 updates per request. Note that the number of statements per 
request is twice the number of updates since each update is paired with one 
query to fetch the object. All tests are run at 512 concurrency.  The response 
is analogous to the multiple-query test. 
plain text - In this test, the framework responds with the simplest of 
responses: a "Hello, World" message rendered as plain text. The size of the 
response is kept small so that gigabit Ethernet is not the limiting factor for 
all implementations. HTTP pipelining is enabled and higher client-side 
concurrency levels are used for this test (see the "Data table" view).

Here, I instead benchmark my django gallery app, using Apache Bench, and so 
forth.  I guess I’ve been over-achieving…

I have to admit, though, that these benchmarks certainly allow everyone to 
play.  

431 cherrypy587 0.0%(0.0%)

Even cherrypy with it’s 587 per second replies with plain-text.  

The tasks seem deceptively (?) simple?  

But looking closer, the data table for each task, gives more details.  For 
example the plain text is run 4 different times, at 4 different client-side 
concurrency levels are used…  But the levels are: 256, 1024, 4096, and 16384.   
That can’t be the concurrency/thread count??!?!?!??  I can believe 1,000 - 
3,000, outrageously high, but believable.  But 16K worth of 
concurrency/threads?  I doubt that Wikipedia even has to dial it that high?

I have to give them points for providing API latency, and framework overhead….  

- Benjamin



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why so fast a web framework?

[Abdur-Rahmaan Janhangeer]

Well,

They don't choose languages per se but choose frameworks based on that
and ... by virtue of that choose languages. Like just to get faster web
services.

The benchmark is pretty much referred to in the Python world, web side like

https://www.starlette.io/
"Independent TechEmpower benchmarks show Starlette applications running
under Uvicorn as one of the fastest Python frameworks available. (*)"

https://github.com/tiangolo/fastapi
... (thanks to Starlette and Pydantic). One of the fastest Python
frameworks available.

Both with links to the benchmarks.

So, while non-web folks don't care, web folks seem to care. And as a web
someone i wanted to know
why is that so.

Kind Regards,

Abdur-Rahmaan Janhangeer
about  | blog

github 
Mauritius
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why so fast a web framework?

[Chris Angelico]

On Fri, Oct 29, 2021 at 3:49 PM Dan Stromberg  wrote:
>
> I care, and I suspect the OP does too.  Usually machine time doesn't matter
> as much as developer time, but API overhead Can matter - especially on a
> busy server.
>
> I wonder if Pypy would do any better?  Or Micropython?  Or Cython?
>
> CPython != Python.
>
> Sometimes this group reminds me of a certain large company I worked for.
> If they didn't have a solution addressing a problem, they'd pretend it
> didn't matter and belittle anyone who questioned that version of reality.
>

That's not strictly true; what's happening here is that someone's
published a cool-looking bar graph but nobody knows what it really
means. I don't feel the need to delve into everyone's benchmarks to
explain why Python is purportedly worse. If someone uses those kinds
of numbers to decide which programming language to use, they have
bigger problems.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why so fast a web framework?

[Dan Stromberg]

I care, and I suspect the OP does too.  Usually machine time doesn't matter
as much as developer time, but API overhead Can matter - especially on a
busy server.

I wonder if Pypy would do any better?  Or Micropython?  Or Cython?

CPython != Python.

Sometimes this group reminds me of a certain large company I worked for.
If they didn't have a solution addressing a problem, they'd pretend it
didn't matter and belittle anyone who questioned that version of reality.


On Thu, Oct 28, 2021 at 9:46 AM Calvin Spealman  wrote:

> Who cares?
>
> On Wed, Oct 27, 2021 at 10:47 PM Abdur-Rahmaan Janhangeer <
> arj.pyt...@gmail.com> wrote:
>
> > @Chris @Peter
> >
> >
> > See that famous benchmark
> >
> > https://www.techempower.com/benchmarks/#section=data-r20
> >
> > Like routinely PHP frameworks appear higher up than py
> > --
> > https://mail.python.org/mailman/listinfo/python-list
> >
> >
>
> --
>
> CALVIN SPEALMAN
>
> SENIOR QUALITY ENGINEER
>
> calvin.speal...@redhat.com  M: +1.336.210.5107
> [image: https://red.ht/sig] 
> TRIED. TESTED. TRUSTED. 
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why so fast a web framework?

[Chris Angelico]

On Fri, Oct 29, 2021 at 6:17 AM Calvin Spealman  wrote:
>
> I don't think there's anything meaningful being compared in that so-called
> "benchmark" at all. There is no evidence that its worth even the smallest
> bit of attention.
>
> You want to write a web service? Do it. Use Python or PHP, or whatever you
> prefer. Do you think your service is "slow"? You won't know until you
> measure *your* service and compare that against actual requirements you
> have. There is no context here to discuss performance and performance can
> *only* be discussed in a context.
>
> "SQL queries per second" is pointless. Why are you making so many SQL
> queries? If you want your service to be more efficient, make fewer queries!
>

In my experience, using PostgreSQL, a more viable metric is
"transactions per second" - throughput is very similar regardless of
the number of queries per transaction. As a general rule, a web
service should be doing at most one transaction per query, so
throughput in requests per second will be equal to transactions per
second plus however many can be returned from cache (which, for some
applications, will be zero).

Sadly, many people still bow down in worship at the little tin god,
while completely ignoring the fact that proper transactional integrity
will improve *business* performance by, yaknow, not losing data... and
it still often works out faster than doing things wrongly.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why so fast a web framework?

[Calvin Spealman]

I don't think there's anything meaningful being compared in that so-called
"benchmark" at all. There is no evidence that its worth even the smallest
bit of attention.

You want to write a web service? Do it. Use Python or PHP, or whatever you
prefer. Do you think your service is "slow"? You won't know until you
measure *your* service and compare that against actual requirements you
have. There is no context here to discuss performance and performance can
*only* be discussed in a context.

"SQL queries per second" is pointless. Why are you making so many SQL
queries? If you want your service to be more efficient, make fewer queries!

On Thu, Oct 28, 2021 at 12:49 PM Abdur-Rahmaan Janhangeer <
arj.pyt...@gmail.com> wrote:

> Me
>
> Like why exactly is that the case, i would not be surprised for rust, C,
> CPP etc
> But as to where the difference comes for two comparatively similar langs.
>
> Kind Regards,
>
> Abdur-Rahmaan Janhangeer
> about  | blog
> 
> github 
> Mauritius
>


-- 

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

calvin.speal...@redhat.com  M: +1.336.210.5107
[image: https://red.ht/sig] 
TRIED. TESTED. TRUSTED. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why so fast a web framework?

[Abdur-Rahmaan Janhangeer]

Me

Like why exactly is that the case, i would not be surprised for rust, C,
CPP etc
But as to where the difference comes for two comparatively similar langs.

Kind Regards,

Abdur-Rahmaan Janhangeer
about  | blog

github 
Mauritius
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why so fast a web framework?

[Calvin Spealman]

Who cares?

On Wed, Oct 27, 2021 at 10:47 PM Abdur-Rahmaan Janhangeer <
arj.pyt...@gmail.com> wrote:

> @Chris @Peter
>
>
> See that famous benchmark
>
> https://www.techempower.com/benchmarks/#section=data-r20
>
> Like routinely PHP frameworks appear higher up than py
> --
> https://mail.python.org/mailman/listinfo/python-list
>
>

-- 

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

calvin.speal...@redhat.com  M: +1.336.210.5107
[image: https://red.ht/sig] 
TRIED. TESTED. TRUSTED. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why so fast a web framework?

[Abdur-Rahmaan Janhangeer]

@Chris @Peter


See that famous benchmark

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

Like routinely PHP frameworks appear higher up than py
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why so fast a web framework?

[Peter J. Holzer]

On 2021-10-27 23:49:59 +0400, Abdur-Rahmaan Janhangeer wrote:
> See this:
> https://github.com/walkor/webman
> 
> Why similar frameworks do not exist in Python. Is it because
> of lack of lib contributors or due to an inherent difference in Py
> and PHP? Thanks!

The comparison table contains only PHP based frameworks.

How do you know that no Python based frameworks of similar performance
exist?

(And is the benchmark even meaningful?)

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why so fast a web framework?

[Chris Angelico]

On Thu, Oct 28, 2021 at 6:52 AM Abdur-Rahmaan Janhangeer
 wrote:
>
> See this:
> https://github.com/walkor/webman
>
> Why similar frameworks do not exist in Python. Is it because
> of lack of lib contributors or due to an inherent difference in Py
> and PHP? Thanks!
>

It depends entirely on what that benchmark is measuring, and how
tightly that framework was optimized for the benchmark. In real-world
code, performance is seldom dictated by the framework. I can get
100TPS with naive code on a naive database implementation, and
improving that is going to be more about improving the database or the
application rather than the framework.

Of course, tools that can't brag about readability, usability,
maintainability, etc, will naturally brag about their benchmark
results, regardless of how significant - or otherwise - they really
are.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list