0

私は、内部Webアプリケーションがパフォーマンスの問題に直面している理由を調査する任務を負っています。

Webアプリケーション自体は一部がPHPで作成され、一部がPerlで作成されており、パフォーマンスの低下の原因が発生していると思われるMySQLデータベースがあります。

システムには約400人のユーザーがいますが、そのほとんどはさまざまなタイムゾーンに分散しているため、通常、一度にオンラインで使用できるユーザーは最大30人です。特に過去1年間、データベースが拡大し続けるにつれて、パフォーマンスの問題が発生しました。

システムは、1台の32ビットDebianサーバー（6GBのRAM、8 x2.4GHzのIntelCPU）で実行されています。これはおそらく、手元の仕事には十分ではありません。ただし、私がオンラインの唯一のユーザーである場合でも、ページの読み込み時間が遅くなる可能性があります。

スケールアップする必要があるのか​​、スケールアウトする必要があるのか​​を判断しようとしています。まず、私たちのハードウェアがそれに課せられた要求にどれだけうまく対処しているかを知りたいです。次に、負荷を分散するためにスケールアウトしてレプリケーションスレーブを作成する価値があるかどうか。

インターネット上にはたくさんのツールがあります-おそらく調査するには少し多すぎます。誰かが私の探求に役立つかもしれないいくつかのプロファイリング/パフォーマンスモニタリングを提供できるツールをお勧めできますか？

どうもありがとう、 ns

4

2 に答える 2

5

速度低下は、同時ユーザー数ではなく、データに関連しているようです。

適切にインデックス付けされたクエリは、データ量に応じて対数的にスケーリングする傾向があります。つまり、データを 2 倍にすると、一定の C だけクエリ時間が増加し、同じ C だけデータを再度 2 倍にし、同じ C だけ再び 2 倍にするなどです。膨大な量のデータがありますが、クエリは少し遅くなります。

あなたのケースでスローダウンが緩やかでなかった場合 (つまり、データ量に比例しているか、さらに悪い場合)、これはクエリの最適化が不十分であることを示している可能性があります。問題にさらに鉄を投げ込むと延期されますが、予算が無制限でない限り、ある時点で根本原因を実際に解決する必要があります。

  1. 実際のデータでクエリのパフォーマンスを測定して、遅いクエリを特定します。
  2. 可能な改善のための実行計画を調べます。
  3. 必要に応じて、インデックス作成、クラスタリング、カバーリング、およびその他のパフォーマンス テクニックについて学習します。
  4. そして最後に、その知識を手順 (1) と (2) で特定したクエリに適用します。

他に何も役に立たない場合は、データ モデルについて考えてみてください。場合によっては、「完全に」正規化されたモデルが最高のパフォーマンスを発揮するものではないため、司法的な非正規化が必要になる場合があります。

于 2012-04-04T18:20:55.733 に答える
2

予算がある場合の簡単な (怠惰な) 方法は、それにもう少し鉄分を投入することです。

より良い方法は、スケーリングする場所や方法を決定する前に、ボトルネックを特定することです。遅いのはすべてのページの読み込みですか? それとも特定のページだけ？ほんの数ページの場合は、プロファイラーに投資してください (PHP の場合、xDebug と Zend Debugger の両方でプロファイリングを実行できます)。また、診断を実行するために、ライブ システムに可能な限り類似したテスト システムに投資します (まだ投資していない場合)。

いくつかの統計を収集することもできます。sar などのプログラムを使用したサーバー レベル ( sysstat パッケージから) と、データベース レベル (スロー クエリ ログを実行していますか?) のいずれかです。

于 2012-04-04T17:11:52.263 に答える