私のサイトでは、メインページ（ユーザーがほとんどの時間を費やしている）には最大140のクエリがあります（そのうちの70はdjango-avatarモジュールからのものです-いつか別のクエリを見つけることができるかどうかを確認する必要があります）。ただし、ロードには5秒かかります（メトリックはから取得されますdjango-toolbar）。
クエリの数を170に増やし、ロードにかかる時間を2.5秒（！）に減らすことができます。
そのためにはannotate()、小さなクエリを繰り返して辞書を使用および作成する複雑なクエリを単純化する必要があります。クエリの数は増えますが、アノテーションを削除することで複雑なクエリの負荷を取り除くため、djangoの方が気に入っていることに気付きました。
私は何をすべきか？
PS：MySql私も使っている以外にmemcached
まず、django-debug-toolbarは、自分自身をすばやくチェックするための主観的なパフォーマンスの測定値を提供します。クエリが急増したり、リクエストに以前よりもはるかに長い時間がかかったりした場合は、掘り下げて最適化できるかどうかを確認する必要があることをお知らせします。ただし、一般的な「Webサイトの応答性」タイプのテストには適していません。django-debug-toolbar自体は、データを提供するために多くの非効率性をもたらします。ツールバーを無効にすると、有効になるよりもコードのパフォーマンスが大幅に向上します。本当にサイトを測定したい場合は、プロファイリングバックエンドを使用して、最適な条件下でサイトを激しく攻撃し、ボトルネックが発生した場所に関する統計を提供する必要があります。
とはいえ、取得する時間統計はクエリに依存するだけではありません。また、ファイルI / O、テンプレートレンダリングなどにも依存します。開発でmemcachedを使用している場合、キャッシュされているテンプレートだけであっても、リクエスト間で必然的にキャッシュが発生します。テンプレートを再解析して応答オブジェクトを作成する必要がないため、リクエストから多くの時間がかかります。したがって、170クエリの方が高速であるように見えるかもしれませんが、それはすでにキャッシュが存在するためかもしれません。キャッシュをオフにすると、時間が大幅に長くなる可能性があります。開発中でクエリの負荷を最適化している場合は、に設定してキャッシュを完全に無効にする必要がありますDummyCache。
最後に、開発では、リクエストがローカルからローカルに移動するため、リクエストを転送する実際の時間はそれほど問題になりません。これはほぼ瞬時に行われます。実際のシナリオでは、クライアントがサーバーにリクエストを送信するのに数百ミリ秒かかりました。データベースサーバーがWebサーバーと同じサーバー上にない場合、Webアプリとデータベースの間でリクエストを送受信するのに時間がかかり、最後にクライアントに応答を返すのに時間がかかります。実際の転送時間は、通常、実際のクエリ時間よりも多くのボトルネックを作成することになります。したがって、一般に、より多くの小さなクエリよりも、より少なく、より複雑なクエリの方が常に望ましいです。
基本的に、開発中にこのようなものをテストする変数が多すぎます。django-debug-toolbarのようなものは良いガイドですが、包括的ではなく、絶対確実ではありません。コードを本番環境のようなマシンに配置し、強く叩きます。これが確実に知る唯一の方法です。