主にビデオを提供する LAMP Web サイトを持つクライアントがいます。彼は現在、すべてのコンポーネントを備えた 1 つのサーバーにいます。彼はいくつかのスケーリングの問題を抱えています。役立つテクニックにはどのようなものがありますか。
DB を別のサーバーに分離し、それと Web サーバーの間に GB イーサネットを使用しました。ロード バランシング機能を備えた Web サーバーを追加したり、レプリケーションを備えた MySQL サーバーを追加したりできますか?
可能であれば、どのようにスケーリングするかについて、中規模、大規模、超大規模の例が欲しいです。
ビデオは実際にはjpg画像として来ています。この Web サイトに類似したもの:
http://www.webcams.travel/webcam/1170170095
そして、いくつかの詳細を追加します。1 時間あたりの最大訪問者数は 1000 になると思いますが、それができれば幸運だと思います。1日1000本近いかもしれません。
CloudFront や MemCache などに関するアドバイスは、それらがパフォーマンスの問題の根本に対処していると仮定すると、すべて適切です。
データベース側: プロファイル、プロファイル、プロファイル。DB を別のサーバーに移動することは (おそらく) 良いステップでしたが、この DB インスタンスで実行されているクエリをプロファイリングしていなければ、何を改善する必要があるかわかりません。
最も一般的なクエリでEXPLAINを実行することから始めて、大きなテーブルや成長しているテーブルで不要なシーケンシャル スキャンを実行していないかどうかを確認します。必要に応じて索引を付けます。
使用されていない列を返すクエリはありますか?
他のコメンテーターが心配していたように、グラフィック/ビデオ コンテンツをデータベースから提供していますか? ファイルはファイルシステムに保持し、そこから提供する必要があります。
すべてのテーブルは MyISAM ですか? 頻繁に更新されるテーブルは、 InnoDBに移動することでパフォーマンスが向上する場合があり、そこでは ( MyISAM のテーブルレベルのロックとは対照的に) 行レベルのロックの恩恵を受けることができます。
これらは単純で一般的な推奨事項にすぎません。正確に何が遅いのかについての詳細がなければ、詳細を提供することは困難です。
まず、スケーリングを試みる前にボトルネックが何であるかを知る必要があることに同意します。ここでは、開始するためのいくつかのミルの提案を示します。
データベースからビデオを取得します。どんな状況でもこれがどのように理にかなっているのかわかりません。
サーバーをもう 1 つ追加して、ビデオ コンテンツのみを提供し、HTML/アプリケーションは元のもののままにします。これにより負荷が軽減されるだけでなく、HTTP 接続の制限を克服することでクライアント側のパフォーマンスが向上します。
キャッシュ - これはMemcahceを意味するか、すべてのリクエストに対して動的に処理する代わりに HTML 出力を事前に構築することを意味する場合があります。
幸運にも「超大規模」に到達できる場合は、CDNについて考えるかもしれません。とはいえ、その前に他にも多くのハードルに遭遇することでしょう。
幸運を祈ります。
問題が何であるかを正確に解決する必要があります。一般的な解決策はありません。
実際のハードウェアと、多くのクライアントをシミュレートできるものを使用して、パフォーマンス テスト環境を構築する必要があります。これはかなり高価かもしれません。
問題がデータベースにある場合 (そうである可能性があります)、解決策は多くの場合、データベースを複数のデータベースに分割して、それぞれがデータの一部を保持することです。
しかし、まともな人がビデオを MySQL に保存するとは思いません。もしそうなら、リファクタリングが必要かもしれません。
最初にアプリケーションのプロファイルを作成し、ボトルネックがどこにあるかを確認する必要があります。PHPの場合は、xdebugなどを使用することをお勧めします。データのシリアル化やデータベースとの通信に長い時間を費やしている可能性があります。そのため、Memcachedを使用したキャッシュが役立つ場合があります。
次に、MySQLを使用している場合は、MySQLの低速クエリログ（my.cnfのlog_slow_queries）をオンにします。これを使用して、高価なデータベースクエリが何であるかを把握し、すでに述べたようにEXPLAIN<>を介してそれらのチューニングをターゲットにできることがわかったら使用できます。データベースにいくつかのインデックスを追加するだけでよい場合があります。その時点で、再び高速になります。インデックスを使用しないログクエリなど、他の関連するmy.cnfパラメータがあります。
第三に、YahooのページスピードFirefoxプラグインのようなツールを調べてください-それはいくつかの提案をします（例えば、静的コンテンツをオフロードする、あなたが返すものを圧縮する、あなたが期限切れのヘッダーを持っていることを確認するなど）。おそらくサーバー自体がボトルネックではなく、サードパーティ（外部JS、広告、フラッシュなど）に依存しているため、ページのレンダリングに長い時間がかかります。
ハードウェアを追加する必要がある場所を知るには、Webサーバーと比較してデータベースサーバーがどれだけビジーであるかをある程度把握する必要があります（つまり、フロントエンドロードバランサーを備えた複数のWebサーバーが必要ですか、それとも必要ですか？レプリケーションまたはその両方を備えた複数のデータベースサーバー？）
言うことができる負荷がもっとあると確信しています...
プロファイルを作成して、サイトのさまざまな部分が実際にどの程度の負荷を与えているかを確認します。
負荷のほとんどは実際にビデオを提供していると思います - プロキシを使用して、この作業を 2 番目 (3 番目、4 番目...) のサーバーにリダイレクトします。
バレットの答えは、私がすることとほとんど同じです-ボトルネックを特定し、memcachedを調べ、DBをWebサービスとは別のサーバーに移動するなど.
Amazon には、地理的に近いサーバーからコンテンツを提供するCloudFrontという新しいサービスがあることを付け加えておきます。まだ試していませんが、比較的低コストで負荷を分散できる方法かもしれません。
また、Livejournal と Facebook のシステムのスケーリング方法に関するプレゼンテーションを参照してください。アプリケーションの構造に応じて、いくつかの洞察が得られる場合があります。