Este documento fornece uma visão geral das técnicas e ferramentas que podem ajudá-lo a rodar o seu código Django com maior eficiência - mais rápido, e usando menos recursos do sistema.
\nGeralmente a primeira preocupação que surge é escrever código que funcione, no qual a lógica trabalhe de acordo com o que foi definido para produzir a saída esperada. Algumas vezes, entretanto, isso não será o suficiente para fazer o código funcionar de modo tão eficiente quanto seria o desejado.
\nNesse caso, é preciso algo - e na prática, geralmente uma porção de coisas - para melhorar a performance do código sem, ou ao menos minimamente, afetar o seu comportamento.
\nÉ importante ter uma ideia clara do que você entende por ‘performance’. Não existe uma métrica única para ela.
\nMelhorar a velocidade pode ser o objetivo mais óbvio para um programa, mas algumas vezes outras melhorias de performance podem ser desejadas, tais como menor consumo de memória ou menor consumo de recursos de banda da rede ou do banco de dados.
\nMelhorias em uma área geralmente irão proporcionar melhor performance em outras, mas nem sempre; algumas vezes uma pode vir em detrimento das outras. Por exemplo, uma melhoria na velocidade de execução de um programa pode fazê-lo usar mais memória. Até pior, ela pode ser contraproducente - Se a melhoria na velocidade de execução consumir tanta memória ao ponto de o sistema começa a ficar sem ela, você terá causado mais mal que bem.
\nExistem outras escolhas para ter em mente. O seu próprio tempo é um recurso valioso, mais precioso do que o tempo de CPU. Algumas melhorias podem ser muito difíceis para valer a pena sua implementação, ou podem afetar a portabilidade ou manutenibilidade do seu código. Nem todas as melhorias de performance valem o seu esforço.
\nPortanto, você precisa saber quais melhorias de performance você está querendo obter, e você também precisa ter uma boa razão para caminhar nessa direção - e para tanto você precisa:
\nNão é bom assumir ou simplesmente chutar os locais de ineficiência do seu código.
\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.
\nPainéis de terceiros também estão disponíveis para a barra de ferramentas, que pode (por exemplo) emitir relatórios sobre a performance do cache e tempos de renderização dos templates.
\nExistem vários serviços gratuitos que podem analisar e emitir relatórios de performance das páginas do seu site sob a perspectiva de um cliente remoto HTTP, simulando assim a experiência de um usuário de verdade.
\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.
\nExistem também vários outros serviços pagos que fazem uma análise similar, incluindo alguns capazes de identificar o Django e que podem se integrar com o seu código para diagnosticar sua performance de forma bem mais abrangente.
\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.
\nA esse respeito Python é uma excelente linguagem para se trabalhar, porque soluções que parecem elegantes e mais adequadas geralmente são também as com melhor performance. Como em muitos trabalhos, aprender o que parece correto leva tempo, mas uma das regras mais úteis é:
\nO Django oferece muitas formas diferentes de se resolver um problema, mas só porque é possível fazer algo de uma certa maneira não significa que ela seja a maneira apropriada para resolvê-lo. Por exemplo, você pode acabar descobrindo que é possível calcular a mesma coisa - o número de itens em uma coleção, talvez - em um QuerySet, em Python, ou em um template.
Porém, quase sempre será mais rápido fazer isso em leveis mais baixos do que em leveis mais altos. Em leveis mais altos o sistema tem que lidar com objetos através de múltiplos níveis de abstração e maquinário.
\nIsto é, o banco de dados tipicamente faz coisas mais rápido do que o Python consegue fazer, que por sua vez pode fazê-las mais rápido do que a linguagem de templates.
\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 }}\nDe modo geral, o level mais apropriado para o trabalho é o level mais baixo que alguém está disposto a programar.
\n\nCom frequência ele é custoso (isto é, lento e faminto por recursos) para calcular o valor, então podem existir grandes benefícios em salvá-lo em um cache acessível rapidamente, pronto para a próxima vez em que ele for solicitado.
\nÉ uma técnica suficientemente poderosa e significante que o Django inclui em um vasto framework para caches, assim como outras pequenas peças de funcionalidades envolvendo caches.
\nO framework de “cache” do Django oferece oportunidades muito significativas de ganhos de performance, salvando conteúdo dinâmico de modo que ele não precise ser calculado a cada requisição.
\nPara conveniência, Django oferece diferentes níveis de granularidade de cache: você pode fazer cache da saída de views específicas, ou somente de partes difíceis de se produzir, ou mesmo de um site inteiro.
\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 para este cabeçalho#É comum ter que chamar um método de instância de uma classe mais de uma vez. Se essa função for custosa, fazer isso pode ser um desperdício.
\nUsando o decorator cached_property o valor retornado é salvo por uma property; a próxima vez que a função é chamada nessa instância, ela irá retornar o valor salvo ao invés de calculá-lo novamente. Repare que isso só funciona em métodos que recebem self como seu argumento e que ele muda o método para um property.
Certos componentes Django também tem sua própria funcionalidade de cache, esses são discutidos abaixo nas seções relacionadas a eles.
\nLaziness, ou “preguiça” em português, é uma estratégia complementar ao “caching”. Fazer cache evita reprocessamento através do armazenamento dos resultados; laziness posterga o processamento até que ele seja efetivamente solicitado.
\nLaziness nos permite referenciar coisas antes delas serem instanciadas, ou até mesmo antes de ser possível instanciá-las. Isso pode ser usado de várias formas.
\nPor exemplo, traduções “lazy” podem ser usadas antes da linguagem alvo se quer ser conhecida, isso porque ela não é usada até que a string a ser traduzida seja efetivamente requerida, como em um template renderizado.
\nLaziness é também uma forma de salvar recursos através da tentativa de evitar o trabalho desde o início. Isto é, um aspecto do laziness é não fazer nada até que algo realmente tenha que ser feito, porque pode acontecer de o trabalho não ser necessário. Laziness pode, portanto, ter implicações na performance, e quanto mais custoso for o trabalho, maior o potencial de ganho pelo seu uso.
\nO Python fornece uma série de ferramentas para a avaliação de expressões “lazy”, particularmente através das construções generator e generator expression. É interessante ler mais sobre laziness no Python para descobrir oportunidades de uso desses padrões no seu código.
\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.
Por outro lado, certas operações irão forçar a análise do QuerySet. Evitar a análise prematura de um QuerySet pode salvá-lo de fazer uma desnecessária e custosa viagem até o banco de dados.
O Django também fornece um decorator keep_lazy(). Isso permite que uma função chamada com um argumento lazy se comporte de modo lazy, somente sendo analisada quando for realmente necessário. Assim o argumento lazy - que pode ser um argumento custoso - não será chamado para análise a não ser que isso seja estritamente solicitado.
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.
\nO Django já vem com alguns componentes de middleware úteis que podem ajudar a otimizar a performance do seu site . Eles incluem:
\nConditionalGetMiddlewareLink para este cabeçalho#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 para este cabeçalho#Comprime as respostas para todos os browsers modernos, salvando banda e tempo de transferência. Tenha em mente que atualmente o GZipMiddleware é considerado um risco de segurança, e é vulnerável a ataques que anulam a proteção fornecida pelo TLS/SSL. Veja o warning na classe GZipMiddleware para mais informações.
Usar sessões “cacheadas” pode ser uma forma de melhorar a performance ao eliminar a necessidade de carregar dados de sessão de uma fonte de dados mais lenta como um banco de dados e, ao invés disso, armazenar os dados de sessão mais frequentemente usados em memória.
\nArquivos estáticos, que por definição não são dinâmicos, são um excelente alvo para ganhos de otimização.
\nManifestStaticFilesStorageLink para este cabeçalho#Tomando vantagem das habilidades de cache dos browsers web, você pode eliminar totalmente o uso de banda para um dado arquivo depois de seu download inicial.
\nManifestStaticFilesStorage appends a\ncontent-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.
Várias ferramentas e pacotes Django desenvolvidos por terceiros fornecem a habilidade de “minificar” HTML, CSS, e JavaScript. Eles removem espaços em branco desnecessários, quebras de linhas e encurtam nomes de variáveis, e assim reduzem o tamanho dos documentos que o seu site publica.
\nTenha em mente que:
\nusar {% block %} é mais rápido do que usar {% include %}
Templates muito fragmentados, construídos de várias pequenas peças, podem afetar a performance.
Ativar a classe cached template loader geralmente aumenta a performance drasticamente, já que ela evita compilar cada template novamente sempre que ele tiver que ser renderizado.
Às vezes é bom verificar se versões diferentes e com melhor performance do software que você utiliza estão disponíveis.
\nEstas técnicas são para os usuários mais avançados que querem expandir as fronteiras de performance de um site Django já bem otimizado.
\nEntretanto, elas não são soluções mágicas para problemas de performance, e elas provavelmente trarão pouco ou nenhum ganho para sites que já não façam as coisas mais básicas do jeito correto.
\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.
\nIsso é o que tem acontecido no Django em si. Sucessivas novas releases têm oferecido um número de melhorias em todo o sistema, mas você ainda deverá verificar a performance de sua aplicação no mundo real, pois em alguns casos você pode acabar descobrindo que mudanças significam um pior desempenho ao invés do contrário.
\nNovas versões do Python, e também de suas bibliotecas, também irão com frequência possuir um melhor desempenho - mas meça, ao invés de assumir isso.
\n\nPara praticamente todos os casos, a linguagem de templates embutida no Django é perfeitamente adequada. Porém, se o gargalo no seu projeto Django parecer ser o sistema de template e você tiver exaurido outras oportunidades de remediar isso, uma alternativa de terceiros pode ser a resposta.
\nJinja2 can offer performance improvements, particularly when it comes to\nspeed.
\nSistemas de template alternativos variam no quanto eles usam da linguagem de template do Django.
\n\nPode ser útil checar se o software Python que você está usando foi fornecido em uma implementação diferente que pode executar o mesmo código mais rápido.
\nEntretanto: a maioria dos problemas de performance em sites Django bem escritos não estão no nível de execução Python, mas sim em consultas ineficientes ao banco de dados, caches e templates. Se você estiver se apoiando em código Python mal escrito, seus problemas de performance provavelmente não serão resolvidos ao serem executados mais rápido.
\nUsar uma implementação alternativa pode introduzir problemas de compatibilidade, implantação, portabilidade, ou manutenção. Nem é preciso dizer que antes de adotar uma implementação atípica você deve se certificar de que ela fornece ganhos de performance suficientes para a sua aplicação que compensem o risco em potencial.
\nCom essas ressalvas em mente, você deve conhecer:
\nPyPy is an implementation of Python in Python itself\n(the ‘standard’ Python implementation is in C). PyPy can offer substantial\nperformance gains, typically for heavyweight applications.
\nA key aim of the PyPy project is compatibility with existing Python APIs and libraries.\nDjango is compatible, but you will need to check the compatibility of other\nlibraries you rely on.
\nAlgumas bibliotecas Python também são implementadas em C, e podem ser muito mais velozes. Elas visam oferecer as mesmas APIs. Tenha em mente que problemas de compatibilidade e diferenças de comportamento não são desconhecidos (e nem sempre evidentes imediatamente).
\n