LogicMonitorでは、非公式のセッションで交代で互いに学び合っています。 XNUMX週間は、開発者がMySqlとNoSQLについて話しているかもしれません。 またはマーケティング担当者がリード生成やアドワーズなどについて話します。今回はプログラミング言語のトピックと、プログラマーの効率を犠牲にしてアセンブラーまたはCを使用する場合のコード速度と効率の間のトレードオフについて説明しました。 Ruby onRailsやPython / Djangoなど、より高いレベルの抽象化を備えた言語を使用する場合、コードの効率を犠牲にしてプログラマーの生産性が大幅に向上します。
誰かが、その抽象化と非効率性が重要かどうかを尋ねました。ほとんどの運用上の問題と同様に、それは重要な場合にのみ重要です。 つまり、使用頻度の低いシステムを作成している場合、または強力なハードウェアを使用している場合は、まったく問題にならない可能性があります。 ただし、ワークロードが突然増加した場合は、非常に重要になる可能性があります。 （Twitterの失敗したクジラとRoRスケーリングの初期の発生を参照してください。）
次に、コードを変更したときに改善されているかどうかをどのようにして知ることができるかという質問がありました。 もちろん、トレンドを作りましょう。 おそらく、アプリケーションのパフォーマンスを制約するものは何か知っているでしょう。 （そうでない場合は、 より良い監視。）多くのサイトでは、明らかな制約はXNUMX秒あたりのデータベースクエリである可能性があります。 したがって、時間の経過とともにWebリクエストごとにデータベースクエリをプロットします
たとえば、LogicMonitorでは、以下のように定義されたカスタムダッシュボードグラフを使用して、顧客から報告された監視データと相関するデータベースアクティビティを追跡します。 XNUMX秒あたりのMysqlの質問を、XNUMX秒あたりに報告されるデータセットの数で割るだけです。
そして結果は次のとおりです。
したがって、50月初旬にコードが変更され、報告されたデータセットごとのデータベースルックアップの数が約XNUMX％減少したことは明らかです。 その後、事態を悪化させた別の変更が元に戻されました。
このようなグラフは、コード変更のパフォーマンスへの影響を追跡するために不可欠です。このサーバーの負荷は常に変化するため、MySQLグラフだけを見るのは困難です。Dbの質問に大きな変更がある可能性がありますが、負荷の変更が原因です。 、コードではありません。 ロードドライバー（Web要求、またはレポートされたデータ）を制約（この場合はDBクエリ）に関連付けることにより、ロードではなく、コードの影響のみを評価できます。
そして、このアプローチの利点は、実際の入力をさまざまな制約に結び付けることができることです。 あなたはチャートを作ることができます：
- WebサーバーCPUへのWeb要求
- DB操作へのWeb要求（つまり、質問に関連するようなものですが、クエリキャッシュが応答できなかった質問のみ）。
- メインDBを保持しているボリュームのNetAppディスク操作へのWeb要求
- 考えられる制約への主要な入力。
コードがリクエストを多かれ少なかれ効率的にしていて、スケーラビリティに影響を与えているかどうかがわかります。 インフラストラクチャの変更（たとえば、memcachedのデプロイ）が大きな違いを生んでいるかどうかがわかります。
スケーリングを行い、ハードウェアに多額の費用をかけずにそれを実行し、コードの改善に役立てるために開発チームに提供する実際の実用的な情報がある場合、このアプローチは素晴らしいステップです。
もちろん、LogicMonitorをご利用で、この種のトレンドやダッシュボードの設定についてサポートが必要な場合は、無料で設定できます。