web-dev-qa-db-ja.com

Linux上のApache / Varnish / MySQLを使用したサーバーアーキテクチャの最適化

私はサイドベンチャーとしての小規模な新興企業のサーバー管理者です(つまり、私はこのテーマについて十分な経験を積んだ専門家ではありません)。最近、サイトを単一のWindowsマシンからRackspace上のマシンのクラスターに移動するのを手伝いました雲。

現在、サイトのベンチマークは約600リクエスト/秒ですが、割り当てられたリソースの量を考えると、はるかに高い可能性があると思います。

現在、8台のWebサーバーの前でRackspace Cloud Load Balancer(Apache Zeus)を使用しています。各Webサーバーは512MBのクラウドインスタンスでLinuxを実行しており、コンテンツはApache2バックエンドを備えたVarnishによって提供されています。

Webアプリケーション自体はPHPです。 Apacheはmpm-workerで実行されており、phpはfcgiで実行されています。 PHP APCも有効になっています。

データベースバックエンドに関しては、マスターマスターレプリケーションセットアップでMySQLにサービスを提供する2つの4GBサーバーインスタンスがあり、Webサーバーの半分が各サーバーを指しています。このアプリケーションは非常にデータベースを集中的に使用するため、データベース専用のリソースが非常に多くあります。

通常、パフォーマンスは良好ですが、既存のインフラストラクチャでは処理できない負荷スパイクが発生したため、ノードのサイズを動的に増やしました。これはうまくいきましたが、特定の負荷条件の下では、サイトを高速に維持するために予想していたよりも多くのリソースをインフラストラクチャに投入する必要があったと感じています。私の調査では、ワニスの個別のインスタンスが非常に多いという点で非常に珍しい設定を使用しているようです。キャッシュレイヤーのオプションを検討する必要があるかもしれません。

現在のアーキテクチャの概要が描かれています ここ(グーグルドキュメントリンク)

ラックスペースクラウドの価格モデルはかなり直線的です。つまり、1024MBのサーバーインスタンスは512MBのインスタンスのコストのちょうど2倍です。そのため、同じ量のリソース(コスト)内で作業しながら、パフォーマンスを最大化することを目指しています。

私の最初の考えは、Apacheバックエンドの前にワニスの単一インスタンスを使用することを優先してラックスペースロードバランサーを削除し、おそらくApacheバックエンドを8x512mbインスタンスではなく4x1gbインスタンスにすることです。ロードバランサーのコストは非常に安いため、別の専用サーバーに置き換えることを正当化するには、パフォーマンスの向上を大きくする必要があります。

HAProxyやNginxのアイデアもいじってみましたが、本番サイトでやみくもに実験を始めたくありません。

私の目標は、ほぼ同じハードウェア割り当てで2000 req/sに近いサービスを提供できるようにすることです。

編集:しばらくの間mod_pagespeedを動作させていたため、約100 req/s上昇しましたが、相互作用に多くの問題があるようでしたニス付き。

編集:Varnish VCL 、ディスクはRackspace Cloudのデフォルト(非san、SATAを推測)、データベースは現在約1.5GB 。通常の状態ではディスクへのスワップはありません。 Apacheプロセスはそれぞれ約20MBです。 php-cgiプロセスは、より多くのリソースをかみ砕く傾向があります。

6
WerkkreW

私は1つの高RAMを使用します(ワニスRAMワニスツールを使用して使用量を確認し、問題がなくなるまで増やします)ワニスインスタンスとロードバランサーなし(または2つのワニスとロードバランサー高可用性が必要)および必要な数のApacheサーバー...アプリがCPUバウンド(サーバー数が多い)またはRAMバウンド(MEMが高いサーバー)の場合)はあなた次第です。

また、キャッシュ設定(どのくらいの期間キャッシュできるか)を試してみると役立ちます。

1
Silent-Bob

OP、いくつかの無料のベンチマーキングには http://blitz.io を使用できます。また、いくつかのコマンドラインベンチマーキングツールについては、「ab」と「httperf」を調べてください。

ワニスは最小限の構成で大成功を収めて使用できます。また、PHP重いアプリを使用する場合は、APCをインストールすることをお勧めします。

2
Ramon Long