Python djangoアプリケーションでNewRelic監視のパフォーマンスオーバーヘッドを数値化するため

Question

私は、複数のアプリケーションサーバー、MySQLサーバーなどを含む大規模なDjango（v1.5.1）アプリケーションに取り組んでいます。必要なすべてのサーバーにNewRelicを展開する前にトランザクションごとにどのようなオーバーヘッドが発生するかを知ることができます。

可能であれば、アプリケーション追跡と理想的なサーバー監視を区別したいと思います。

誰もがこれについて一般に認められている番号を知っていますか？おそらく、このような調査や手順を行っているサイトで、私たち自身で調査を行うことができます。

Answer 1

PythonエージェントとDjango Webアプリケーションの監視では、要求ごとのオーバーヘッドは、計測された特定の要求内で実行される関数の数によって決まります。これは、完全なプロファイリングが行われていないためです。代わりに、関心のある特定の機能だけが計測される。したがって、ネストした関数がインスツルメンテーションされた関数でなければ、ネストされた呼び出しではなく、その1つの関数呼び出しに対してラッパーを実行するオーバーヘッドのみです。

Djangoに組み込まれている特定の関数は、ミドルウェアとビューハンドラ関数、テンプレートレンダリング、および各テンプレートブロックを扱うテンプレートレンダラー内の関数です。 Djangoとは異なり、クエリーを実行するための低レベルのデータベースクライアントモジュール関数、memcacheとWeb外部などの計器を持っています。

これは、特定のWeb要求実行が100個の計装機能余分なオーバーヘッドが発生するのはそれだけです。代わりに、ビュー・ハンドラーが多数の異なるデータベース照会を実行した場合、または非常に複雑なテンプレートをレンダリングした場合、計装された関数の数がさらに多くなり、そのようなWeb要求のオーバーヘッドが増えます。つまり、ビュー・ハンドラがより多くの作業を行っている場合は、それほど複雑でないものよりも応答時間が長くなります。

つまり、要求ごとのオーバーヘッドは固定されておらず、実行されている作業の数、さらにはインスツルメントされた関数の数によって異なります。したがって、物量を数量化して、オーバヘッドごとに要求ごとに一定の値を与えることはできません。

これはいくらかのオーバーヘッドがあり、一般的な目標範囲は約5％です。

一般的に何が起こるかは、パフォーマンスメトリックが得られたことから得られる洞察が、ほとんどの顧客にとっては、ほとんど直ちに発見できる非常に簡単な改善があることを意味します。このような変更を加えれば、応答時間は、監視を開始する前の状態に戻すことができます。したがって、監視をしていない時点から開始することになります。さらなる掘削とチューニングを行うことで、改善がさらに劇的になる可能性があります。提供されるパフォーマンスメトリックの特定の側面に注意を払い、WSGIサーバーを調整し、使用率を向上させ、必要なホスト数を減らしてホスティングコストを削減することもできます。