0

最適化した PHP の画像提供スクリプトがあります。私は最適化のサーバー側で多くの作業を行ってきましたが、mysql 側の最適化も確実に行いたいと考えています。現在、この画像提供スクリプトをロードするたびに、MYSQL で次のアクションを実行しています。

  1. データベースに接続する
  2. 提供された ID が有効かどうかを確認し、有効な場合は行を返します。
  3. ヒット列の数を 1 増やして、画像の統計を更新します。
  4. 同様に、特定のコントローラーとアクションで統計テーブルを 1 増やします。
  5. 接続を閉じません。時間がかからず、自然に死ぬので、そのままにしておくように言われました

サーバーで「mysqladmin status」を実行したところ、現在実行中の平均が 63.8997 であることがわかりました。現在、このスクリプトをロードする apache を通過する要求/秒は約 17 です。また、このスクリプトのコンパイル済みバージョンをすぐに使用できるように、サーバー上で eaccelerator を構成しました。私の質問は、処理できるクエリの数をさらに最適化する方法はありますか? すべての # を可能な限り低く保ち、できるだけ速く移動するようにしていますか?

私の目標は、サーバーで 1 日 432 万件のイメージ サーブを問題なく処理することです (Apache では 1 秒あたり 50 件です)。

4

2 に答える 2

1

カウンターをインクリメントして DB にコミットするたびに、おそらくディスクに書き込みます。代わりに、ヒット数をメモリに数分間キャッシュし、数分ごとにキャッシュをデータベースにダンプして戻すことができます。これにより、データベースに対する書き込みと読み取りの回数が減ります。

さらに一歩進んで、行全体をメモリにキャッシュすることもできます。これは、データが頻繁に変更されず、データが頻繁に要求される場合にのみ実用的です。また、大量のデータをキャッシュし始めると、メモリの制約が問題になる場合があります。

一部の非常に高性能なデータベース環境では、データベース インスタンス全体がメモリに格納され、ディスクへの書き込みが定期的にしか行われないことを知っています。これにより、クエリ時間も大幅に短縮され、すべてが既にメモリ内にあるため、キャッシュの必要性が減少します。ただし、これにはいくつかの深刻なハードウェアが必要です。

さらに、最終的に MySQL から離れたいと思うかもしれません。MySQL はハイ パフォーマンスには最適ではありません。つまり、MySQL とストアド プロシージャはうまく連携できないからです。ストアド プロシージャはデータベース上でコンパイルされ、実行するために SQL を解析する必要はありません。たとえば Oracle のようなものに切り替える場合、このトランザクション全体をコンパイル済みストアド プロシージャで実行できます。MySQL がこの柔軟性を提供するのは、たとえあったとしても簡単ではありません。

于 2012-05-02T19:09:02.900 に答える
0

複数のレプリカ読み取りサーバーを用意し、それを使用してデータを提供し、1 つの統計サーバーで次のことを行う必要があります。

INSERT DELAYED INTO stats (image) VALUES (:image);

これにより、水平方向にスケーラブルな読み取りサービスと高速な統計カウンターが提供されます。

または画像形式で（効果のあるもの）：

ここに画像の説明を入力

于 2012-05-02T18:54:18.997 に答える