On the surface, the first impression is that a web framework is slow because
there is a lot of boiler plate and unnecessary code that is not needed for
your application, and that is a valid impression. In practice, slowness is
usually not a product of your framework’s bloat or the language choice.
Slowness is likely a result of the fact that your request is communicating
with other services across your network. In our case, these other services
are PostgreSQL, Redis, Cassandra, and Memcached, just to name a few. Slow
database queries and network latency generally outweigh the performance
overhead of a robust framework such as Django.
The correct way to read this is that even if you can super-optimize your app layer, focusing on network communications will probably yield better results. We usually hear that the database is the bottleneck. That’s true if it means that we are asking the database to do too much and/or too many times. I sometimes wonder how many web pages out there still do tens of queries per request, involving chained JOINs (“thanks” to magical ORMs), and filtering out the final results on the client side, after initializing tons of objects.
Original title and link: Scaling Django to 8 Billion Page Views: What is slow ( ©myNoSQL)