This document provides an overview of techniques and tools that can help get\nyour Django code running more efficiently - faster, and using fewer system\nresources.
\nGenerally one's first concern is to write code that works, whose logic\nfunctions as required to produce the expected output. Sometimes, however, this\nwill not be enough to make the code work as efficiently as one would like.
\nIn this case, what's needed is something - and in practice, often a collection\nof things - to improve the code's performance without, or only minimally,\naffecting its behavior.
\nIt's important to have a clear idea what you mean by 'performance'. There is\nnot just one metric of it.
\nImproved speed might be the most obvious aim for a program, but sometimes other\nperformance improvements might be sought, such as lower memory consumption or\nfewer demands on the database or network.
\nImprovements in one area will often bring about improved performance in\nanother, but not always; sometimes one can even be at the expense of another.\nFor example, an improvement in a program's speed might cause it to use more\nmemory. Even worse, it can be self-defeating - if the speed improvement is so\nmemory-hungry that the system starts to run out of memory, you'll have done\nmore harm than good.
\nThere are other trade-offs to bear in mind. Your own time is a valuable\nresource, more precious than CPU time. Some improvements might be too difficult\nto be worth implementing, or might affect the portability or maintainability of\nthe code. Not all performance improvements are worth the effort.
\nSo, you need to know what performance improvements you are aiming for, and you\nalso need to know that you have a good reason for aiming in that direction -\nand for that you need:
\nIt's no good just guessing or assuming where the inefficiencies lie in your\ncode.
\ndjango-debug-toolbar is a very handy tool that provides insights into\nwhat your code is doing and how much time it spends doing it. In particular it\ncan show you all the SQL queries your page is generating, and how long each one\nhas taken.
\nThird-party panels are also available for the toolbar, that can (for example)\nreport on cache performance and template rendering times.
\nThere are a number of free services that will analyze and report on the\nperformance of your site's pages from the perspective of a remote HTTP client,\nin effect simulating the experience of an actual user.
\nThese can't report on the internals of your code, but can provide a useful\ninsight into your site's overall performance, including aspects that can't be\nadequately measured from within Django environment.
\nThere are also several paid-for services that perform a similar analysis,\nincluding some that are Django-aware and can integrate with your codebase to\nprofile its performance far more comprehensively.
\nSome work in optimization involves tackling performance shortcomings, but some\nof the work can be built-in to what you'd do anyway, as part of the good\npractices you should adopt even before you start thinking about improving\nperformance.
\nIn this respect Python is an excellent language to work with, because solutions\nthat look elegant and feel right usually are the best performing ones. As with\nmost skills, learning what "looks right" takes practice, but one of the most\nuseful guidelines is:
\nDjango offers many different ways of approaching things, but just because it's\npossible to do something in a certain way doesn't mean that it's the most\nappropriate way to do it. For example, you might find that you could calculate\nthe same thing - the number of items in a collection, perhaps - in a\nQuerySet, in Python, or in a template.
However, it will almost always be faster to do this work at lower rather than\nhigher levels. At higher levels the system has to deal with objects through\nmultiple levels of abstraction and layers of machinery.
\nThat is, the database can typically do things faster than Python can, which can\ndo them faster than the template language can:
\n# QuerySet operation on the database\n# fast, because that's what databases are good at\nmy_bicycles.count()\n\n# counting Python objects\n# slower, because it requires a database query anyway, and processing\n# of the Python objects\nlen(my_bicycles)\n<!--\nDjango template filter\nslower still, because it will have to count them in Python anyway,\nand because of template language overheads\n-->\n{{ my_bicycles|length }}\nGenerally speaking, the most appropriate level for the job is the lowest-level\none that it is comfortable to code for.
\n\nOften it is expensive (that is, resource-hungry and slow) to compute a value,\nso there can be huge benefit in saving the value to a quickly accessible cache,\nready for the next time it's required.
\nIt's a sufficiently significant and powerful technique that Django includes a\ncomprehensive caching framework, as well as other smaller pieces of caching\nfunctionality.
\nDjango's caching framework offers very significant\nopportunities for performance gains, by saving dynamic content so that it\ndoesn't need to be calculated for each request.
\nFor convenience, Django offers different levels of cache granularity: you can\ncache the output of specific views, or only the pieces that are difficult to\nproduce, or even an entire site.
\nImplementing caching should not be regarded as an alternative to improving code\nthat's performing poorly because it has been written badly. It's one of the\nfinal steps toward producing well-performing code, not a shortcut.
\ncached_propertyLink to this heading#It's common to have to call a class instance's method more than once. If\nthat function is expensive, then doing so can be wasteful.
\nUsing the cached_property decorator saves the\nvalue returned by a property; the next time the function is called on that\ninstance, it will return the saved value rather than re-computing it. Note that\nthis only works on methods that take self as their only argument and that\nit changes the method to a property.
Certain Django components also have their own caching functionality; these are\ndiscussed below in the sections related to those components.
\nLaziness is a strategy complementary to caching. Caching avoids\nrecomputation by saving results; laziness delays computation until it's\nactually required.
\nLaziness allows us to refer to things before they are instantiated, or even\nbefore it's possible to instantiate them. This has numerous uses.
\nFor example, lazy translation can be used before the\ntarget language is even known, because it doesn't take place until the\ntranslated string is actually required, such as in a rendered template.
\nLaziness is also a way to save effort by trying to avoid work in the first\nplace. That is, one aspect of laziness is not doing anything until it has to be\ndone, because it may not turn out to be necessary after all. Laziness can\ntherefore have performance implications, and the more expensive the work\nconcerned, the more there is to gain through laziness.
\nPython provides a number of tools for lazy evaluation, particularly through the\ngenerator and generator expression constructs. It's worth\nreading up on laziness in Python to discover opportunities for making use of\nlazy patterns in your code.
\nDjango is itself quite lazy. A good example of this can be found in the\nevaluation of a QuerySet. QuerySets are lazy.\nThus a QuerySet can be created, passed around and combined with other\nQuerySet instances, without actually incurring any trips to the database\nto fetch the items it describes. What gets passed around is the QuerySet\nobject, not the collection of items that - eventually - will be required from\nthe database.
Di sisi lain, t:ref:certain operations will force the evaluation of a QuerySet 1. Mengindari penilaian sebelum waktunya dri QuerySet dapat menyimpan membuat perjalanan mahal dan tidak diperlukan pada basisdata.
Django juga menawarkan penghias keep_lazy(). Ini mengizinkan sebuah fungsi yang telah dipanggil dengan argumen lazy untuk berperilaku malas itu sendiri, hanya sedang dinilai ketika itu dibutuhkan. Dengan demikian argumen lazy - yang dapat sangat mahal - tidak akan dipanggil untuk penilaian sampai itu semata-mata diperlukan.
Django's database layer provides various ways to help developers get the best\nperformance from their databases. The database optimization documentation gathers together links to the relevant\ndocumentation and adds various tips that outline the steps to take when\nattempting to optimize your database usage.
\nDjango comes with a few helpful pieces of middleware\nthat can help optimize your site's performance. They include:
\nConditionalGetMiddlewareLink to this heading#Adds support for modern browsers to conditionally GET responses based on the\nETag and Last-Modified headers. It also calculates and sets an ETag if\nneeded.
GZipMiddlewareLink to this heading#Compresses responses for all modern browsers, saving bandwidth and transfer\ntime. Note that GZipMiddleware is currently considered a security risk, and is\nvulnerable to attacks that nullify the protection provided by TLS/SSL. See the\nwarning in GZipMiddleware for more\ninformation.
Using cached sessions may be a way to increase\nperformance by eliminating the need to load session data from a slower storage\nsource like the database and instead storing frequently used session data in\nmemory.
\nStatic files, which by definition are not dynamic, make an excellent target for\noptimization gains.
\nManifestStaticFilesStorageLink to this heading#By taking advantage of web browsers' caching abilities, you can\neliminate network hits entirely for a given file after the initial download.
\nManifestStaticFilesStorage appends\na content-dependent tag to the filenames of static files to make it safe for browsers to cache them\nlong-term without missing future changes - when a file changes, so will the\ntag, so browsers will reload the asset automatically.
Beberapa alat-alat pihak-ketiga Django dan peket-paket menyediakan kemampuan untuk "minify" HTML, CSS, dan JavaScript. Mereka memindahkan ruang kosong yang tidak diperlukan, baris baru, dan komentar, dan memperpendek nama-nama variabel, dan mengurangi ukuran dari dokumen-dokumen yang situs anda terbitkan.
\nCatat bahwa:
\nmenggunakan {% block %} lebih cepat daripada menggunakan {% include %}
heavily-fragmented templates, assembled from many small pieces, can affect\nperformance
Enabling the cached template loader often improves performance\ndrastically, as it avoids compiling each template every time it needs to be\nrendered.
It can sometimes be worth checking whether different and better-performing\nversions of the software that you're using are available.
\nThese techniques are targeted at more advanced users who want to push the\nboundaries of performance of an already well-optimized Django site.
\nHowever, they are not magic solutions to performance problems, and they're\nunlikely to bring better than marginal gains to sites that don't already do the\nmore basic things the right way.
\n\nIt's fairly rare for a new release of well-maintained software to be less\nefficient, but the maintainers can't anticipate every possible use-case - so\nwhile being aware that newer versions are likely to perform better, don't\nassume that they always will.
\nThis is true of Django itself. Successive releases have offered a number of\nimprovements across the system, but you should still check the real-world\nperformance of your application, because in some cases you may find that\nchanges mean it performs worse rather than better.
\nNewer versions of Python, and also of Python packages, will often perform\nbetter too - but measure, rather than assume.
\n\nFor nearly all cases, Django's built-in template language is perfectly\nadequate. However, if the bottlenecks in your Django project seem to lie in the\ntemplate system and you have exhausted other opportunities to remedy this, a\nthird-party alternative may be the answer.
\nJinja2 can offer performance improvements, particularly when it comes to\nspeed.
\nAlternative template systems vary in the extent to which they share Django's\ntemplating language.
\n\nIt may be worth checking whether Python software you're using has been\nprovided in a different implementation that can execute the same code faster.
\nHowever: most performance problems in well-written Django sites aren't at the\nPython execution level, but rather in inefficient database querying, caching,\nand templates. If you're relying on poorly-written Python code, your\nperformance problems are unlikely to be solved by having it execute faster.
\nUsing an alternative implementation may introduce compatibility, deployment,\nportability, or maintenance issues. It goes without saying that before adopting\na non-standard implementation you should ensure it provides sufficient\nperformance gains for your application to outweigh the potential risks.
\nWith these caveats in mind, you should be aware of:
\nPyPy adalah penerapan Python di Python itu sendiri (penerapan Python 'standar' ada di C). PyPy dapat menawarkan peningkatan kinerja yang substansial, biasanya untuk aplikasi kelas berat.
\nA key aim of the PyPy project is compatibility with existing Python APIs and libraries.\nDjango is compatible with versions of PyPy corresponding to the supported\nPython versions, but you will need to check the compatibility of other\nlibraries you rely on.
\nBeberapa pustaka Python juga menerapkan di C, dan dapat lebih cepat. Mereka bermaksud menawarkan API sama. Catat bahwa masalah kesesuaian dan perbedaan kebiasaan tidak diketahui (dan tidak selalu segera jelas).
\n