VPSで実行されるapache / php / mysqlを高負荷に最適化する

512mのRAMを搭載したVPSでのapache / mysqlサーバーの最適化に関する質問。通常の負荷では、すべてが高速で実行され、接続の遅延はありません。ただし、トラフィックの多い日（5万回以上のアクセス）を取得すると、サイトがクロールされ、Apacheからコンテンツを取得するのに30秒以上かかります。

このサイトはExpression Engine（CMS）（PHP）で実行されており、私は彼らの高負荷最適化ガイドに従っています。私はグーグルで検索し、かなりの数のApacheを運んで、現在の場所に到達しましたが、一定の応答時間を取得する必要があります。

これは、（私がやろうとしていることのために）十分なRAMを持っているため、ここでの「低メモリ用に最適化」の質問とは異なると思われます。私は、サーバーが高負荷で窒息しないようにする必要があります。

再表現はありますか？

PHPには、容量を増やす2つの重要なことがあります。

1. 前述の高度なPHPキャッシュ（APC）。これがYahoo!で使用するものです。他にも同様のプロジェクトがありますが、これはラスマスの赤ちゃんです。
2. mod_phpの代わりにFastCGI。mod_phpは通常最速であるため、この問題については議論があります。ただし、動的なPHPコンテンツと静的なアセット（JS、CSS、フラッシュ、画像、PDFなど）の両方を配信する単一のApacheサーバーがあると仮定します。これらの静的アセットに対するリクエストは、それほど多くのメモリを消費する必要はありませんが、PHPはモジュールであるため、すべてのApacheスレッドにあります。

Apacheの場合：

1. ワーカーMPMを使用する
2. キープアライブを有効にする

ApacheからLighttpdまたはNginxへの切り替えを検討することもできます。Apacheが大好きです。私は、その高度な機能の多くの愚か者を使います。私はそれが提供するものが必要なため、そのオーバーヘッドを受け入れます。一般的なLAMPスタックの場合、必要以上に多くのリソースが無駄になります。

MySQLの場合：

1. 最適化の努力は、my.cnf値を微調整する代わりに、クエリの分析と修正に費やすときに10倍の成果を上げます。キャッシングや接続などを正しくすることは重要ではないと言っているわけではありませんが、ほとんどの人にとっては問題の9％に過ぎません。
2. QA中に、staging / dev mysqld の一般クエリログをオンにして、送信されたすべてのクエリをキャプチャします。（実稼働mysqlサーバーでそれをしないでください！）
3. EXPLAINを使用して、クエリを分析します。特に、ORMを備えたフレームワークを使用している場合（DBを抽象化し、独自のSQLを記述できないようにする場合）、余分なJOIN、WHERE句のないSELECT、「ファイルソートの使用」を引き起こすORDER BY、およびクエリを削除する必要がありますインデックスを使用しません。
4. MySQL 5.1 を使用している場合は、クエリプロファイラーを利用してください。

検討に値する他のツールはmk-visual-explainです

私は10の素晴らしい参考文献を引用しました。これらのことはあなたをハミングさせるべきです。どうなるか教えてください。

PHPセッションファイルをtmpfsに移動し、APC（またはその他）を使用して、不要なすべての PHPモジュールを削除します。必要のない/使用しないApacheモジュールをすべて削除します。

tmpfs（RAMのディレクトリ！）を作成するには

mkdir /tmpfs; chmod 777 /tmpfs
mount -t tmpfs -o size=256M tmpfs /tmpfs

中に/ etc / fstabを再起動時に、それを作成するために、以下の行を追加します！

tmpfs     /tmpfs    tmpfs   size=256m,mode=0777    0       0

で/etc/apache2/php.ini RAM（tmpfsの）であなたのセッションを保存するために調整！

session.save_handler = files
session.save_path = "/tmpfs"

注：RAM内のPHPファイルとセッションファイルを使用すると、ディスクにほとんど触れません。

ブラウザがほとんどのものをキャッシュするように、apacheでexpires_moduleを使用します。

ExpiresActive On
ExpiresDefault "access plus 90 days"
ExpiresByType image/gif "access plus 90 days"
ExpiresByType image/ico "access plus 90 days"
ExpiresByType image/png "access plus 90 days"
ExpiresByType image/jpeg "access plus 90 days"
ExpiresByType image/x-icon "access plus 90 days"
ExpiresByType text/css "Access plus 90 days"
ExpiresByType text/html "Access plus 90 days"
ExpiresByType application/x-shockwave-flash "Access plus 90 days"
ExpiresByType application/x-javascript "Access plus 90 days"

.htaccessファイルを使用しないでください！代わりに、vhost構成ファイルにハードコーディングしてください！すべてのhttpリクエストごとにディスクチェックを大幅に削除/削減します...本当に加算されます。

Options FollowSymLinks 
AllowOverride None

vhost.confファイルで使用される.htaccessの例 ...

<Directory /home/user/www/site.com/secure>
    Order Allow,Deny
    Deny from All
</Directory>

いくつかのことが思い浮かびます。

オペコードキャッシュは常に良いアイデアです。APC よりもhttp://eaccelerator.net/の方が好きです。APCを追加しようとしている途中でAPCを使用して開発していない場合は、ほとんど常に苦痛です。Eacceleratorは派手ではありませんが、機能しているようです。

リバースプロキシも良いアイデアですが、RAMの使用量を監視する必要があります。Apache 2.2でmpm-workerを使用すると、かなりの量のRAMを単独で使用できます。あなたの場合、Nginxのようなより軽いものをお勧めし、PHPでApacheをFASTCGIとして実行するか、プロセスごとにそのままにしておきます。Varnish、Squid、Nginxなどを使用するアイデアは、静的コンテンツを提供し、ユーザー接続を処理し、アプリケーションサーバーとして扱うApacheにのみPHPリクエストを渡すことです。

少なくとも5.1.24など、かなり新しいバージョンのMysql 5.1を実行している場合、1秒未満のスローログにアクセスできます。long_query_timeを1または2から開始し、実際に長いものを処理するときに0.5に引き下げます。Mysqlのネットには一般的なチューニング情報もたくさんありますが、多くのことをするRAMがありません。デフォルトから設定を増やしましたか？ほとんどのデフォルトのmy.cnfファイルは、約64MBのRAMを使用するように構成されています。少なくとも、key_bufferを16MBから64MBに上げます。

さらに、MyisamまたはInnodbテーブルを使用していますか？DBでセッションを維持する場合は、行レベルのロックではなくテーブルレベルのロックを行うMysiamテーブルを残すのではなく、セッションテーブルをInnodbに変更（または代わりにCookieに）します。基本的に、20％を超えて80％を読み取るテーブルは、Innodbに移行する候補です。MyisamテーブルとInnodbテーブル間でRAMの量のバランスを取る必要があることを忘れないでください。これは、それぞれのバッファーが個別に構成されているためです。

そして最後に、別の512MBのRAMがセットアップに大いに役立ち、さらに安いかほぼ同じ価格であれば、MySQLを実行するために別の512MB VPSになります。実際に2番目のインスタンスを使用すると、使用可能なディスクIOが2倍になるためです。VPSサーバーの問題の1つは、IOが同じ物理サーバー上の他の人から保護されていないことです。

うーん、私の投稿はまあまあまあまあですが、見るべき場所がたくさんあります。幸運を。

• apcのようなphpにはオペコードキャッシュを使用します。
• squidやニスなどのhttpアクセラレータを使用します。

メモリが少ない状況（トラフィックが多いサーバーの場合は512Mbが低い）では、WebサーバーとDBエンジンの選択を検討する価値があります。

Lighttpは、Apacheが多くの微調整を行った後に通常作成できるよりもすぐに軽量であり、それよりも軽いオプションがあります。もちろん、依存するApache機能が他のサーバーでサポートされていない場合、これは不可能です。

sqliteはmySQLよりもはるかにタイトで、多くの条件下でも高速です。使用しているエンジンがこれをサポートしているかどうか、また試してみるかどうかを確認してください。

もう1つのオプションである簡単なオプションは、余裕があればVMのRAMを増やすことです。

ここでの素晴らしい提案を超えて、すべてのVPSが同等に作成されているわけではないことに注意してください。私の経験では、PHPはCPUが重いことが判明しました。

EC2上のnginx / apc / phpfpm / mysql（local）のWordpress ABベンチマーク（ab -n 500 -c 25 http://domain.com/index.php）は、エントリレベル「2GB RAM / 1 Compute Unitサーバー」。

512MB Rackspace Cloudserver上の同じ正確なスタック（同一のOSにスクリプトによってデプロイされた）に対して実行された同じベンチマークは、〜80 req / secondを返します。したがって、この初歩的な実験では、ラムが4倍、パフォーマンスが40倍になります。

ABの最中を見ると、EC2は並行性を処理できず、すぐに100％のCPU負荷に達し、ロックアップすることがわかります。同じベンチマーク中に512MBサーバー（仮想化されたクアッドコアCPU）の上部を表示すると、コアは〜60％の負荷に達し、ベンチマークをスムーズに処理します。

VPSは非常に簡単に起動したり停止したりすることができ、コミットすることなく、VM / VPSが存在するインフラストラクチャをテストに使用しても問題ありません。

編集1：また、EC2の「高CPU」スモールインスタンスは、CPUが依然としてボトルネックのままで、〜10 / req秒しか生成できませんでした。私の結論は、EC2の安定性/堅牢性のためにパフォーマンスを犠牲にすることであり、もちろんそのような環境を必要とする多くのユースケースがあります。