{"id":111,"date":"2017-03-30T09:48:32","date_gmt":"2017-03-30T09:48:32","guid":{"rendered":"https:\/\/159.69.80.24\/blog\/django-performance-optimization-tips\/"},"modified":"2025-10-21T12:28:34","modified_gmt":"2025-10-21T12:28:34","slug":"django-performance-optimization-tips","status":"publish","type":"post","link":"https:\/\/djangostars.com\/blog\/django-performance-optimization-tips\/","title":{"rendered":"Django Performance Optimization Tips for 2024"},"content":{"rendered":"

We, as a Django development company<\/a>, frequently faces a recurring situation when developers receive a task to make a performance optimization on Django. Pretty often they are trying to make it in the wrong way.<\/p>\n

In this short article I want to show how to improve django performance, shed some light on the common mistakes in Django performance optimization, and show you the way I\u2019m searching for bottlenecks. This is based on my hands-on experience with Python and Django, including working at Django Stars, where the Django framework is one of the cores in various projects<\/a>.<\/p>\n

Database optimization<\/h2>\n

I saw how people start the optimization of database queries in Django that take about 5% of all the request for so many times. Unfortunately, most of the developers simply add select_related<\/code>\/prefetch_related<\/code> to their Django QuerySets to decrease the count of queries to the database. That decreases the number of queries indeed, but what about time? When tuning the orm in Django<\/a>, test on real data and use select_related<\/code>\/prefetch_related<\/code> only if pages load faster\u2014not just to cut query count. Such changes will increase the amount of time needed to complete the request, and what is more important it can increase the time needed on production server significantly.<\/p>\n

Never try to optimize queries on your development machine<\/h3>\n

The Postgres planner collects statistics about your data that help identify the best possible execution plan for your query. In fact, it will just use heuristics to determine the query plan if the table has little to no data in it. Not only do you need realistic production data in order to analyze reasonable query plans, but also the Postgres server\u2019s configuration has a big effect. For this reason, it\u2019s required that you run your analysis on either the production box, or on a staging box that is configured just like production, and where you\u2019ve restored production data.<\/p>\n

\u2013(an excerpt from the Harold’s Geminez article)<\/a><\/em><\/p>\n<\/blockquote>\n

In terms of Django database optimization, I prefer to have the log of long queries and work with it. It doesn’t matter if that\u2019s going to be a NewRelic or just a PostgreSQL log.<\/p>\n

Code optimization<\/h2>\n

Probably, everyone knows about django-extension<\/code> with RunProfileServer<\/code> but I think that this solution is not very comfortable to work with. It provides you with a lot of data in the format that is quite hard to read.<\/p>\n

I use line profiler<\/a> instead. This package allows you to check the Django performance of specific parts of the code. For Django model methods and properties, avoid doing database work inside @property<\/code>; move heavy logic into queries or cache it, and verify with line_profiler<\/code>. Basically, you have to write the script to evaluate code that you need and put @profile<\/code> decorator to methods you are interested in.<\/p>\n

As a result, you will receive:<\/p>\n