このドキュメントでは、Django コードをより効率よく、早く、より少ないリソースで実行するためのテクニックとツールについて、その概要を説明します。
\n一般に、最も関心があるのは、コードが正しく 動作する、つまり、書かれたコードのロジックがが期待通りの出力を生成することです。しかし、それだけでは、期待通りに 効率よく 動作しているとは言えません。
\nこの場合、必要なのは、コードの振る舞いに影響を与えることなく、あるいは影響を最小限に保ちつつ、そのパフォーマンスを向上させる実用的な方法です。
\n最適化する「パフォーマンス」という言葉で何を意味しているのか、はっきりと考えておくことが大切です。パフォーマンスを測る指標は1つではないからです。
\n高速化というものがプログラムのために最も明らかな目的かもしれません。しかし、他の観点からパフォーマンスを向上することもできます。たとえば、メモリー消費量を少なくするとか、データベースやネットワークのアクセス量を削減するといったことが考えられます。
\n1つの領域を改善すると、別の領域の性能も向上することがよくありますが、常にそうとは限らず、一方が他方を犠牲にすることさえあります。たとえば、プログラムの速度の改善がメモリ使用量の増加を引き起こすかもしれません。さらに悪いことに、それが自滅的になるかもしれません。もし速度の改善がメモリを大幅に消費してしまったら、システム上のメモリが足りなくなり、結果的に利益よりも害を与えることになってしまうでしょう。
\n他にも気に留めておく必要があるトレードオフがあります。あなた自身の時間が CPU 時間以上に貴重なリソースだということです。一部の改善は実装する価値がないほど難しすぎるかもしれず、ポータビリティやコードメンテナンスに影響を与えてしまうかもしれません。すべての性能改善に努力する価値があるわけではないのです。
\nそのため、何を目的としたパフォーマンスの改善なのかを知っておくべき必要があります。また、その目的とした方針に相応の理由があるかを知っておく必要もあります。
\nコード中で効率の悪い部分を、単に想像したり当て推量したりするというのは、あまり良い考えではありません。
\ndjango-debug-toolbar は非常に便利なツールで、コードが何をしているか、どのくらいの時間を費やしているかを把握するのに役立ちます。特に、ページが生成しているすべてのSQLクエリと、それぞれのクエリにかかった時間を表示することができます。
\nサードパーティ製のパネルをツールバーに追加することも可能です。それにより、たとえば、キャッシュのパフォーマンスや、テンプレートのレンダリング時間を測定できます。
\nサイト上のページのパフォーマンスを分析・レポートしてくれる無料のサービスが数多く存在します。これらのサービスでは、実際のユーザーエクスペリエンスをリモートの HTTP クライアントの観点からシミュレートしてくれます。
\nこれらのサービスは、コードの内部についてレポートすることはできませんが、Django 環境の内部からは十分に測定できない観点も含めて、サイト全体のパフォーマンスについて役に立つ見解を提供してくれます。
\n同様の分析を実施する有料サービスもいくつかあり、一部は Django を認識するため、コードベースと統合して性能のプロファイルをより包括的に得られます。
\n最適化には、パフォーマンスの悪い部分を改善する作業も含まれますが、パフォーマンスの向上を考える前に取り入れるべき点として、どんな場合でも作業に採用できる良い習慣があります。
\nこの点においてPython は優れた言語であり、エレガントに見え、正しいと感じる解決策が通常、最も性能が良いものです。ほとんどのスキルと同様に、「正しいと見える」ものを学ぶには実践が必要ですが、最も有用なガイドラインの一つはこれです:
\nDjango は様々なアプローチ方法を提供しますが、ある方法で何かができるからといって、それが最も適切な方法であるとは限りません。例えば、同じこと (コレクション内のアイテムの数など) を QuerySet で、 Python で、あるいはテンプレートで計算できるかもしれません。
しかし、この作業を高いレベルよりも低いレベルで行う方が、ほとんどの場合、速くなります。高いレベルでは、システムは複数の抽象化レベルとマシンの層を通じてオブジェクトを扱わなければなりません。
\nつまり、データベースは通常、Pythonよりも速く処理ができ、Pythonはテンプレート言語よりも速く処理ができます:
\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 }}\n通常、その仕事に最も適したレベルは、コードを書くのに快適な最も低いレベルのものです。
\n\n値の計算は高コストになる（つまり、リソースを多く消費し、遅い）ことが多いので、その値をすぐにアクセス可能なキャッシュに保存しておくことで、次に必要になる時のための大きなメリットになります。
\nこれは十分に重要で強力な技術なため、Djangoには包括的なキャッシュフレームワークと他の小さなキャッシュ機能の部品が含まれています。
\nDjango の キャッシュフレームワーク は、動的なコンテンツを保存して、リクエストごとに再計算しないで済むようにすることで、パフォーマンスを向上するための非常に大きな可能性を提供します。
\n利便性のため、Django は様々なレベルのキャッシュの粒度を提供しています。特定のビューの出力をキャッシュしたり、生成するのに時間のかかるパーツだけをキャッシュしたり、あるいは、サイト全体をキャッシュすることでさえ可能です。
\nキャッシュの実装は、書き方が良くないことが原因でパフォーマンスが悪いコードを改善する手段として考えるべきではありません。キャッシュは、パフォーマンスの良いコードを生み出すための最終段階の一つであり、近道ではありません。
\ncached_propertyLink to this heading#クラスのインスタンスのメソッドを複数回呼ぶ必要があるというのはよくあることです。その関数の実行が高コストである場合、複数回の呼び出しは無駄が多いです。
\ncached_property デコレータを使うことで、プロパティが返す値を保存して、次回同じインスタンスで関数が呼ばれた時、その値を再計算する代わりに、保存しておいた値を返すようにすることができます。ただし、このデコレータが機能するのは、メソッドが引数として self のみを取り、メソッドをプロパティーに変えられる場合のみなので、注意してください。
特定の Django コンポーネントは、独自のキャッシュ機能を実装しています。以下のそれらのコンポーネントに関係するセクションで解説します。
\n遅延 (laziness) とは、キャッシュ機能を補完するもう1つの戦略です。キャッシュは結果を保存することで再計算を防ぎますが、遅延は実際に値が必要になるまで、計算の実行を遅らせます。
\n遅延によりインスタンス化される前に、またはインスタンス化が可能になる以前であっても参照できるようになります。これにはさまざまな用途があります。
\nたとえば、遅延翻訳 は対象となる言語自体が判別される前に使用できます。翻訳後の文字列がレンダリングされたテンプレートなどで実際に必要になるまで使用されなくなるためです。
\nそもそも怠惰（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 は遅延をうまく使います。このよい例として、QuerySet の評価が挙げられます。QuerySet は遅延評価されます。そのため、QuerySet は作成後、記述したアイテムを取得するためにデータベースへのアクセスを一切行うことなく、さまざまな場所に渡したり、他の QuerySet インスタンスと組み合わせることができます。渡されるのは QuerySet オブジェクトであって、最終的にはデータベースから取得されるアイテムのコレクションではないのです。
他方で、特定の操作は QuerySet の評価を強制します。QuerySet の時期尚早な評価を回避することで、高コストで不必要なデータベースへのアクセスを節約できます。
Django には keep_lazy() デコレータもあります。これにより、遅延引数で呼び出された関数は、必要なときだけ評価されるようになります。このため、遅延引数 (高コストな引数である可能性もあります) は、必要なときだけ評価されるようになります。
Djangoのデータベース層は、開発者がデータベースを最大限活用できるように、さまざまな方法を提供しています。 データベースアクセスの最適化ドキュメント では、データベースの利用を最適化する際にとるべき手順を、大まかにいくつかの見出しとしてまとめています。それぞれの見出しの下に、関連するドキュメントへのリンクを集約した上で、さまざまなヒントを追加しています。
\nDjango は、サイトのパフォーマンス改善に役立ついくつかの ミドルウェア を用意しています。以下のようなものがあります。
\nConditionalGetMiddlewareLink to this heading#モダンなブラウザが ETag と Last-Modified ヘッダを元に条件的にレスポンスを GET するためのサポートを追加します。
GZipMiddlewareLink to this heading#すべてのモダンブラウザのレスポンスを圧縮し、帯域幅と転送時間を節約します。ただし、GZipMiddleware は現在セキュリティリスクと見なされており、TLS/SSL によって提供される保護を無効にする攻撃に対して脆弱です。詳細については、 GZipMiddleware の警告を参照してください。
キャッシュされたセッションの使用 は、データベースのような遅いストレージソースからセッションデータを読み込む必要をなくし、頻繁に使用されるセッションデータをメモリ内に保存することで、パフォーマンスを向上させるかもしれません。
\n静的ファイル (定義により、動的に生成されないファイル) は、最適化を施すのに格好のターゲットです。
\nManifestStaticFilesStorageLink to this heading#ウェブブラウザのキャッシュ機能を利用することで、あるファイルを最初にダウンロードした後のネットワークヒットを完全に無くすことができます。
\nManifestStaticFilesStorage は、ブラウザが将来の変更を見逃すことなく長期間にわたって安全にキャッシュできるように、 静的ファイル のファイル名に内容依存のタグを追加します。ファイルが変更されるとタグも変更されるため、ブラウザは自動的にアセットをリロードします。
いくつかのサードパーティ製の Django ツールやパッケージは、HTML、CSS、そして JavaScript を最小化する ("minify") 機能を提供します。これらは不要なホワイトスペースや改行、コメントを取り除き、変数名を短縮することで、サイトが公開するドキュメントのサイズを削減してくれます。
\n注意:
\n{% block %} の使用は {% include %} より高速です。
多数の分割されたテンプレートパーツからページを生成すると、パフォーマンスに影響することがあります。
cached template loader を有効にすると、パフォーマンスが劇的に改善する場合が多いです。このローダーを使用することで、テンプレートのレンダリングが必要になった場合に、各テンプレートを毎回コンパイルせずに済むようになるためです。
現在使用しているソフトウェアの、より性能の高い別バージョンが利用可能かどうかを確認する価値がある場合もあります。
\nこれらのテクニックは、すでに最適化された Django サイトのパフォーマンスの限界に挑戦したい上級ユーザーを対象としています。
\nしかし、これらはパフォーマンス問題に対する魔法のような解決策ではありませんし、より基本的なことをすでに正しい方法で行っていないサイトに、わずかな利益以上のものをもたらす可能性は低いでしょう。
\n\nよくメンテナンスされたソフトウェアの新しいリリースの動作が遅くなることはかなり稀ですが、メンテナーはすべてのユースケースを予測することはできません。そのため、新しいバージョンは性能が向上する可能性が高いことを認識しつつも、常にそうであると仮定するべきではありません。
\nこれは Django 自体にも当てはまります。リリースを重ねるごとに、システム全体にわたって多くの改良が施されていますが、アプリケーションの実際のパフォーマンスを確認するべきです。なぜなら、場合によっては変更によってパフォーマンスが向上するどころか悪化する可能性もあるからです。
\nPythonの新しいバージョンや、Pythonパッケージの新しいバージョンも、しばしばパフォーマンスが向上しますが、推測するのではなく、実際に測定してください。
\n\nほとんど全ての場合において、Django の組み込みテンプレート言語は十分です。しかし、もしあなたの Django プロジェクトのボトルネックがテンプレートシステムにあると見られ、それを改善するための他の機会を使い果たしたのなら、サードパーティ製の代替手段が解決策になるかもしれません。
\nJinja2 を使うと、パフォーマンス、特に速度の向上が得られる可能性があります。
\n代替テンプレートシステムは、Django のテンプレート言語をどの程度共有するかによって異なります。
\n\nあなたが使っているPythonソフトウェアが、同じコードをより速く実行できる別の実装で提供されていないか確認する価値があるかもしれません。
\nしかし、適切に書かれた Django サイトのほとんどのパフォーマンス問題は、Python の実行レベルではなく、非効率なデータベースクエリ、キャッシュ、およびテンプレートにあります。もし、不適切に書かれた Python コードに依存している場合、それがより速く実行されるようになっても、パフォーマンス問題が解決されることはありません。
\n別の実装を使用すると、互換性、デプロイメント、移植性、メンテナンスの問題が発生する可能性があります。非標準の実装を採用する前に、それが潜在的なリスクを上回る十分なパフォーマンスをアプリケーションにもたらすことを確認する必要があることは言うまでもありません。
\nこれらの注意事項を念頭に置いた上で、次の項を読んでください:
\nPyPy は Python 自身で書かれた Python 実装です ('標準の' Python 実装は C で書かれています)。heavyweight なアプリケーションの場合、PyPy を使用するとパフォーマンスが大幅に向上する可能性があります。
\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.
\n一部の Python ライブラリは C 言語で実装されており、はるかに高速です。これらは同じ API を提供することを目指しています。互換性の問題や振る舞いの違いが存在することが知られています（そして、それらは常にすぐには明らかにならないこともあります）。
\n