Django benchmark is low

[Gary]

Hi all,

Why Django has low benchmark?
https://www.techempower.com/benchmarks/

Pls share your views.

[Aymeric Augustin]

Hello Gary,

https://www.techempower.com/benchmarks/#section=data-r14&hw=ph&test=plaintext says Django can serve 88,019 requests per second. That's about 11µs per request (1µs = 1e-6s).

Response times for Django-powered sites are typically in the 50-500ms range (1ms = 1e-3s).

The framework overhead is low enough compared to the time spent in the application that it isn't a priority in the development of Django. Ease of use by developers is considered more important.

Using the Python language is a good example of this philosophy. Python is easier for developers than many other languages but harder for computers, thus slower to execute.

We're still trying to write efficient code. I believe Sergey Fedoseev performed a series of performance optimizations in Django 2.0. But we aren't optimizing for microbenchmarks.

Best regards,

-- 

Aymeric.

-- 
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/de61fafa-362a-4d4d-b98d-071f779ab94d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jamesie Pic]

Well, they're using tornado as frontend serveur, perhaps they should try with uwsgi.

[Levi Cameron]

What is 'low'?

[1] Microbenchmarks don't reflect reality

It's pretty easy to make one framework look good if you play to it's strengths: eg json serialization -- django looks pretty good but that's only because most of the time is spent in C code doing json serialization, it's not really reflective of real world performance. Even more complicated benchmarks rarely reflect the true complexity and requirements of a real-world app (eg Flask looks simple, streamlined and fast until you realise that it's missing so many features that need to be provided with extra packages -- and now you've just reinvented django).

[2] You should optimize for developers, not servers

You can compare any non-compiled language with C++ frameworks and they will look pretty slow, but unless you are Google developer salaries are more expensive than writing something that scales horizontally and just buying more servers.

Django's strength has always been developer productivity, performance only needs to be 'good enough' for it to usually be a better choice than eg Rust.

[3] Most frameworks have equivalent performance: the database is the bottleneck

But let's do an apples-apples comparison anyway: rails-unicorn, symfony2, cakephp, web2py, laravel-php5-raw, pyramid-py3, zend, yii2, codeigniter.

Django is middle of the pack -- but they're all close enough that it doesn't really matter. For a normal web app with SQL backend framework performance can scale linearly with the number of frontend servers. The database can't. It's more important then that you have a good DB structure & SQL queries, and all of the major frameworks are good enough to do that.

[4] Techempower

• django plaintext benchmark, django json benchmark: how many of your pages really look like this? This just testing wsgi application overhead: a trivial consideration in a real-world app. If you really care about shaving 3% off a request then buy faster servers. If you really care about serving up a "Hello World" text file at maximum speed then use a CDN.
  
• django db benchmark code: no transactions, no business logic, no ORM goodies (eg slicing/limit/offset, joins, automatic type conversion), minimal/no template processing, no consideration of multi-threaded vs multi-process code, trivial URL routing, optimisations (eg this) that noone would do in reality
  

These are not limitations specific to techempower, they're limitations of all microbenchmarks that target lowest common denominator functionality.