--- title: "Penampilan dan optimalisasi" version: 6.0 locale: id source: https://docs.djangoproject.com/id/6.0/topics/performance/ canonical: https://djangodocs.dev/id/6.0/topics/performance/ --- # Penampilan dan optimalisasi This document provides an overview of techniques and tools that can help get your Django code running more efficiently - faster, and using fewer system resources. ## Kata Pengantar Generally one's first concern is to write code that *works*, whose logic functions as required to produce the expected output. Sometimes, however, this will not be enough to make the code work as *efficiently* as one would like. In this case, what's needed is something - and in practice, often a collection of things - to improve the code's performance without, or only minimally, affecting its behavior. ## Pendekatan umum ### What are you optimizing *for*? It's important to have a clear idea what you mean by 'performance'. There is not just one metric of it. Improved speed might be the most obvious aim for a program, but sometimes other performance improvements might be sought, such as lower memory consumption or fewer demands on the database or network. Improvements in one area will often bring about improved performance in another, but not always; sometimes one can even be at the expense of another. For example, an improvement in a program's speed might cause it to use more memory. Even worse, it can be self-defeating - if the speed improvement is so memory-hungry that the system starts to run out of memory, you'll have done more harm than good. There are other trade-offs to bear in mind. Your own time is a valuable resource, more precious than CPU time. Some improvements might be too difficult to be worth implementing, or might affect the portability or maintainability of the code. Not all performance improvements are worth the effort. So, you need to know what performance improvements you are aiming for, and you also need to know that you have a good reason for aiming in that direction - and for that you need: ### Penampilan pembandingan It's no good just guessing or assuming where the inefficiencies lie in your code. #### Alat-alat Django [django-debug-toolbar](https://pypi.org/project/django-debug-toolbar/) is a very handy tool that provides insights into what your code is doing and how much time it spends doing it. In particular it can show you all the SQL queries your page is generating, and how long each one has taken. Third-party panels are also available for the toolbar, that can (for example) report on cache performance and template rendering times. #### Layanan pihak-ketiga There are a number of free services that will analyze and report on the performance of your site's pages from the perspective of a remote HTTP client, in effect simulating the experience of an actual user. These can't report on the internals of your code, but can provide a useful insight into your site's overall performance, including aspects that can't be adequately measured from within Django environment. There are also several paid-for services that perform a similar analysis, including some that are Django-aware and can integrate with your codebase to profile its performance far more comprehensively. ### Mendapatkan hal yang benar dari awal Some work in optimization involves tackling performance shortcomings, but some of the work can be built-in to what you'd do anyway, as part of the good practices you should adopt even before you start thinking about improving performance. In this respect Python is an excellent language to work with, because solutions that look elegant and feel right usually are the best performing ones. As with most skills, learning what "looks right" takes practice, but one of the most useful guidelines is: #### Bekerja pada tingkatan sesuai Django offers many different ways of approaching things, but just because it's possible to do something in a certain way doesn't mean that it's the most appropriate way to do it. For example, you might find that you could calculate the same thing - the number of items in a collection, perhaps - in a `QuerySet`, in Python, or in a template. However, it will almost always be faster to do this work at lower rather than higher levels. At higher levels the system has to deal with objects through multiple levels of abstraction and layers of machinery. That is, the database can typically do things faster than Python can, which can do them faster than the template language can: ``` # QuerySet operation on the database # fast, because that's what databases are good at my_bicycles.count() # counting Python objects # slower, because it requires a database query anyway, and processing # of the Python objects len(my_bicycles) ``` ```html+django {{ my_bicycles|length }} ``` Generally speaking, the most appropriate level for the job is the lowest-level one that it is comfortable to code for. > **Note** > > Contoh di atas hanyalah ilustrasi. > > Firstly, in a real-life case you need to consider what is happening before > and after your count to work out what's an optimal way of doing it *in that > particular context*. The database optimization document describes [a > case where counting in the template would be better](/id/6.0/topics/db/optimization/#overuse-of-count-and-exists). > > Secondly, there are other options to consider: in a real-life case, `{{ > my_bicycles.count }}`, which invokes the `QuerySet` `count()` method > directly from the template, might be the most appropriate choice. ## Menembolok Often it is expensive (that is, resource-hungry and slow) to compute a value, so there can be huge benefit in saving the value to a quickly accessible cache, ready for the next time it's required. It's a sufficiently significant and powerful technique that Django includes a comprehensive caching framework, as well as other smaller pieces of caching functionality. ### The caching framework 1 Django's [caching framework](/id/6.0/topics/cache/) offers very significant opportunities for performance gains, by saving dynamic content so that it doesn't need to be calculated for each request. For convenience, Django offers different levels of cache granularity: you can cache the output of specific views, or only the pieces that are difficult to produce, or even an entire site. Implementing caching should not be regarded as an alternative to improving code that's performing poorly because it has been written badly. It's one of the final steps toward producing well-performing code, not a shortcut. ### [`cached_property`](/id/6.0/ref/utils/#django.utils.functional.cached_property) It's common to have to call a class instance's method more than once. If that function is expensive, then doing so can be wasteful. Using the [`cached_property`](/id/6.0/ref/utils/#django.utils.functional.cached_property) decorator saves the value returned by a property; the next time the function is called on that instance, it will return the saved value rather than re-computing it. Note that this only works on methods that take `self` as their only argument and that it changes the method to a property. Certain Django components also have their own caching functionality; these are discussed below in the sections related to those components. ## Memahami laziness *Laziness* is a strategy complementary to caching. Caching avoids recomputation by saving results; laziness delays computation until it's actually required. Laziness allows us to refer to things before they are instantiated, or even before it's possible to instantiate them. This has numerous uses. For example, [lazy translation](/id/6.0/topics/i18n/translation/#lazy-translations) can be used before the target language is even known, because it doesn't take place until the translated string is actually required, such as in a rendered template. Laziness is also a way to save effort by trying to avoid work in the first place. That is, one aspect of laziness is not doing anything until it has to be done, because it may not turn out to be necessary after all. Laziness can therefore have performance implications, and the more expensive the work concerned, the more there is to gain through laziness. Python provides a number of tools for lazy evaluation, particularly through the [generator](https://docs.python.org/3/glossary.html#term-generator) and [generator expression](https://docs.python.org/3/glossary.html#term-generator-expression) constructs. It's worth reading up on laziness in Python to discover opportunities for making use of lazy patterns in your code. ### Laziness di Django Django is itself quite lazy. A good example of this can be found in the evaluation of a `QuerySet`. [QuerySets are lazy](/id/6.0/topics/db/queries/#querysets-are-lazy). Thus a `QuerySet` can be created, passed around and combined with other `QuerySet` instances, without actually incurring any trips to the database to fetch the items it describes. What gets passed around is the `QuerySet` object, not the collection of items that - eventually - will be required from the 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()`](/id/6.0/ref/utils/#django.utils.functional.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. ## Basisdata ### Optimasi basisdata Django's database layer provides various ways to help developers get the best performance from their databases. The [database optimization documentation](/id/6.0/topics/db/optimization/) gathers together links to the relevant documentation and adds various tips that outline the steps to take when attempting to optimize your database usage. ### Other database-related tips Enabling [Hubungan tetap](/id/6.0/ref/databases/#persistent-database-connections) can speed up connections to the database accounts for a significant part of the request processing time. This helps a lot on virtualized hosts with limited network performance, for example. ## Penampilan HTTP ### Middleware Django comes with a few helpful pieces of [middleware](/id/6.0/ref/middleware/) that can help optimize your site's performance. They include: #### [`ConditionalGetMiddleware`](/id/6.0/ref/middleware/#django.middleware.http.ConditionalGetMiddleware) Adds support for modern browsers to conditionally GET responses based on the `ETag` and `Last-Modified` headers. It also calculates and sets an ETag if needed. #### [`GZipMiddleware`](/id/6.0/ref/middleware/#django.middleware.gzip.GZipMiddleware) Compresses responses for all modern browsers, saving bandwidth and transfer time. Note that GZipMiddleware is currently considered a security risk, and is vulnerable to attacks that nullify the protection provided by TLS/SSL. See the warning in [`GZipMiddleware`](/id/6.0/ref/middleware/#django.middleware.gzip.GZipMiddleware) for more information. ### Sesi #### Menggunakan sesi tembolok [Using cached sessions](/id/6.0/topics/http/sessions/#cached-sessions-backend) may be a way to increase performance by eliminating the need to load session data from a slower storage source like the database and instead storing frequently used session data in memory. ### Berkas statis Static files, which by definition are not dynamic, make an excellent target for optimization gains. #### [`ManifestStaticFilesStorage`](/id/6.0/ref/contrib/staticfiles/#django.contrib.staticfiles.storage.ManifestStaticFilesStorage) By taking advantage of web browsers' caching abilities, you can eliminate network hits entirely for a given file after the initial download. [`ManifestStaticFilesStorage`](/id/6.0/ref/contrib/staticfiles/#django.contrib.staticfiles.storage.ManifestStaticFilesStorage) appends a content-dependent tag to the filenames of [static files](/id/6.0/ref/contrib/staticfiles/) to make it safe for browsers to cache them long-term without missing future changes - when a file changes, so will the tag, so browsers will reload the asset automatically. #### "Minifikasi" 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. ## Penampilan cetakan Catat bahwa: - menggunakan `{% block %}` lebih cepat daripada menggunakan `{% include %}` - heavily-fragmented templates, assembled from many small pieces, can affect performance ### The cached template loader Enabling the [`cached template loader`](/id/6.0/ref/templates/api/#django.template.loaders.cached.Loader) often improves performance drastically, as it avoids compiling each template every time it needs to be rendered. ## Menggunakan versi berbeda dari perangkat lunak tersedia It can sometimes be worth checking whether different and better-performing versions of the software that you're using are available. These techniques are targeted at more advanced users who want to push the boundaries of performance of an already well-optimized Django site. However, they are not magic solutions to performance problems, and they're unlikely to bring better than marginal gains to sites that don't already do the more basic things the right way. > **Note** > > It's worth repeating: **reaching for alternatives to software you're > already using is never the first answer to performance problems**. When > you reach this level of optimization, you need a formal benchmarking > solution. ### Terbaru adalah sering - tetapi tidak selalu - terbaik It's fairly rare for a new release of well-maintained software to be less efficient, but the maintainers can't anticipate every possible use-case - so while being aware that newer versions are likely to perform better, don't assume that they always will. This is true of Django itself. Successive releases have offered a number of improvements across the system, but you should still check the real-world performance of your application, because in some cases you may find that changes mean it performs worse rather than better. Newer versions of Python, and also of Python packages, will often perform better too - but measure, rather than assume. > **Note** > > Unless you've encountered an unusual performance problem in a particular > version, you'll generally find better features, reliability, and security > in a new release and that these benefits are far more significant than any > performance you might win or lose. ### Jalan lain ke bahasa cetakan Django For nearly all cases, Django's built-in template language is perfectly adequate. However, if the bottlenecks in your Django project seem to lie in the template system and you have exhausted other opportunities to remedy this, a third-party alternative may be the answer. [Jinja2](https://jinja.palletsprojects.com/) can offer performance improvements, particularly when it comes to speed. Alternative template systems vary in the extent to which they share Django's templating language. > **Note** > > *If* you experience performance issues in templates, the first thing to do > is to understand exactly why. Using an alternative template system may > prove faster, but the same gains may also be available without going to > that trouble - for example, expensive processing and logic in your > templates could be done more efficiently in your views. ### Jalan lain penerapan perangkat lunak It may be worth checking whether Python software you're using has been provided in a different implementation that can execute the same code faster. However: most performance problems in well-written Django sites aren't at the Python execution level, but rather in inefficient database querying, caching, and templates. If you're relying on poorly-written Python code, your performance problems are unlikely to be solved by having it execute faster. Using an alternative implementation may introduce compatibility, deployment, portability, or maintenance issues. It goes without saying that before adopting a non-standard implementation you should ensure it provides sufficient performance gains for your application to outweigh the potential risks. With these caveats in mind, you should be aware of: #### [PyPy](https://www.pypy.org/) [PyPy](https://www.pypy.org/) 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. A key aim of the PyPy project is [compatibility](https://www.pypy.org/compat.html) with existing Python APIs and libraries. Django is compatible with versions of PyPy corresponding to the supported Python versions, but you will need to check the compatibility of other libraries you rely on. #### C menerapkan pustaka Python Beberapa 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).