AmazonAWSマイクロインスタンスのパフォーマンス-Apache2およびPHP
私はApache2を実行している仲間のためにいくつかの作業を開始し、UbuntuでPHP、CPUがいっぱいになっています。私が本当に求めているのは、Microインスタンスを使用することが良いアイデアかどうかについてのアドバイスです。プロダクション/パブリック向けのWebサイト。私の直感はノーであり、StandardまたはHighインスタンスを使用する方が良いと思いますが、AWSで遊んで始めたばかりなので、他の人が何をしたかを確認したかっただけです。
現在、彼はこれらの負荷分散をいくつか実行していますが、インスタンスを強制終了する必要があります。彼のアプリで何が起こっているかをより適切に処理できるようになるまで、Cloudwatchをセットアップして自動的にこれを実行することを検討します。フード。
私はそれがかなり漠然とした質問であることを知っています、そして私はセットアップに関して多くの詳細を提供しませんでした、しかしそれは私がまだ彼のサイトでスピードを上げているということです。
簡単な答え：t1.microを軽視しないでください-それは有能なインスタンスであり、間違いなくPHPサイトを実行できます-しかし、1つのt1.microで動作させることができない場合は、 （複数のt1.microsとは対照的に）より大きなインスタンスを取得します。
長い答え：t1.microインスタンスは、動的コンテンツを生成する能力が非常に高く、複数の小さなサイトにサービスを提供するためにかなりスムーズに実行できます。十分に最適化されたセットアップ（たとえばWordpressキャッシュあり）の場合、t1.microは少なくとも5万ヒット/月を処理する必要があります。ただし、重要なアイデアの1つは物事は十分に最適化されているということです-デフォルトのApacheインストールはt1.microをかなり速くダウンさせます-各リクエストは新しいプロセスを生み出すので-関連するすべてのオーバーヘッドを伴います。
さらに、t1.microにはデフォルトでスワップスペースがありません（実際に使用するよりも安全対策として、スワップスペースとして使用する1GB EBSボリュームをセットアップすると役立つ場合があります。頻繁に使用されている場合は、何かを変える必要があります。
複数のインスタンスを実行する場合は、複数のt1.microインスタンスを実行しないことをお勧めします。 1ドルあたりのパフォーマンスは、大規模なインスタンス（メモリ、I/O、およびCPU）ではるかに優れています。 t1.microに関する他のポイントの1つは、追加のCPUを「バースト」することはできますが、サイクルを「盗む」こともできるということです。 t1.microルートを使用する場合は、間違いなく32ビットインスタンスを使用してください。64ビットレジスタのオーバーヘッドが追加されると、具体的なパフォーマンスの向上なしに、インスタンスのメモリ不足が容易になります。
可能であれば、mod_phpの代わりにphp-fpmを使用することをお勧めします-少し遅くなりますが、インスタンスへの負荷が少なく、はるかに大量のトラフィックに耐えることができます。さらに、可能であれば、静的コンテンツの提供をオフロードします。後者の場合、CloudfrontなどのCDNを使用できます（またはS3を使用することもできます）。これらのリクエストは、インスタンスの帯域幅、ディスクI/O、または処理能力（またはメモリ）を消費しないという考えです。または、軽量のフロントエンドサーバー（nginxなど）を使用して静的コンテンツを処理し、動的リクエストをApacheにプロキシして戻すこともできます（そのフロントエンドサーバーの使用に完全に切り替えることができない場合）-これにより、セットアップ-ただし、特にページがキャッシュされている場合（つまり、ページが変更されるたびに静的バージョンが生成される場合）、パフォーマンスが大幅に向上する可能性があります。動的リクエストの不要な処理を回避するために、フロントエンドサーバーで動的コンテンツをキャッシュすることをお勧めします（期間はサイトの人気によって異なります）。
最後の提案の1つは、不可能かもしれませんが、Ubuntuの代わりにAmazonのLinuxをオペレーティングシステムとして使用することを検討してください。 t1.microで非常に軽量で効率的であることがわかりました。インストールされているパッケージが最小限で、フットプリントが非常に小さくなっています。
T1.microで動的Webサイトを実行することは確かに可能です-単一のt1.microでいくつかの小さなサイト（Wordpress/Drupal/Joomla）を実行しました-両方ともnginx/Apache/php-fcgiとvarnish/nginx/phpを使用しています-fpm-メールサーバー（postfix）、imap（dovecot）、データベース（mysql）、およびftpサーバー（pure-ftp/vsftp）を含む-まともなパフォーマンス（Wordpressサイトは1〜2秒でロード）、低負荷平均（通常、0.1未満、15秒ごとの要求に応じて）、および約150〜200MBの使用済みメモリ）。パフォーマンスに関しては私の選択ではありませんが、トラフィックをあまり期待せずに、確実にオンラインにする必要があるサイトにとっては、最もコストのかからないソリューションです。
T1.microは、最適化スキルに取り組むための非常に優れたプラットフォームになると思います。これにより、最小限からどれだけ抜け出すことができるか、どの最適化が価値よりもコストがかかるかを確認できます。ただし、サイトが1つのt1.microに対して単純に大きすぎる場合は、追加のt1.microインスタンスではなく、より大きなインスタンスを使用します（特定の目的がフェイルオーバーである場合を除きますが、その段階では、とにかくより大きなインスタンスを使用する可能性があります）。 。 t1.microインスタンスの負荷を分散しないでください-そのアプローチから得られるものはほとんどありません-インスタンスが大きいほど、より効果的です。ただし、これらのインスタンスが停止している理由を確実に調べたいと思います。これは、CPUの問題ではなく、メモリの問題であると思います。あなたは間違いなくあなたのサイトのコピーを立ち上げて、その上でab（またはseigeなど）を実行して、サーバーが何を立てることができるか、そしてそれがアプリケーション（おそらく変更できない）またはサーバーのセットアップ。
（スポットインスタンスを使用している場合を除き、インスタンスタイプをかなり簡単にアップグレードできます。再起動する前に、停止して（終了せずに）、ec2-modify-instance-attributeを使用してタイプを変更してください）。
t1.microインスタンスは、t1.microインスタンスが処理できるよりも多くのトラフィックを取得しない限り、公開Webサイトに適しています。 （その前の文はあまり言いませんでした。）
アプリケーションが現在作成されている方法でt1.microが処理できるよりも多くのトラフィックを取得しているようですので、より大きなインスタンスタイプにアップグレードする必要があります。
負荷分散t1.microは意味がないと思います。私の意見では、負荷分散の最小値はm1.smallです。それでも、同等のCPUを取得するために必要なm1.smallsの数よりも安いため、c1.mediumを実行する方が良いでしょう。