ウェブサイトの画像をリモートサーバーに移動するvsデータベースをリモートサーバーに移動する
単一のサーバーには大きすぎるwordpressウェブサイトがあります。データベースを外部でホストするかどうか、つまり、DB用に別のサーバーを購入するか、CDNでイメージをホストするかを決定する必要があります。
DBを外部に移動することは、最も迅速で簡単なソリューションです。 I/OとRAMの使用量が低下し、非常に役立ちます。一方、すべてのイメージを別のサーバーに移動すると（AWS S3バケットの使用を考えています）、コアサーバーへのリクエストが大幅に少なくなり、サイトとDBを分離する必要がなくなります。サイトには他のコミュニティベースのツールがあり、人々が画像をアップロードできるため、これはもちろん非常に複雑な手順です。
「最近の投稿」やサイドバーの内容を説明すると、ほとんどのページに15以上の画像があるので、画像をS3に移動すると、最大のメリットが得られるようです。ただし、ブラウザのキャッシュが有効になっているため、これは最初に思われるほど重要ではない場合があります。このサイトのユーザー主導の動的な性質により、ほとんどの場合、ID =セッション値であるユーザーテーブルへの結合が含まれるため、DBクエリをキャッシュできません。このために、私はDBが最も利益を得ると思います。もちろん、DBをlocalhostから移動するという欠点は、インターネット経由でリクエストを行う必要があることを意味します。現在、クラスタまたは内部ネットワークにDBを保存することはできません。データベースはリモートサーバー上にあり、パブリックIPを使用して通信します。
一般的に、平均的なウェブサイトでは、1つしか選択できない場合に最大の利点が得られます。すべての画像を遠隔地に移動し、サブドメイン経由で提供します。 images.mysite.comまたはDBを専用のサーバーに移動する必要がありますか？
現在、2TBディスク、8コアxeon @ 2.7ghz、16GB RAMを備えた専用のスタンドアロンサーバーがあります。 100MBの接続で帯域幅に制限はありません。より大きなものにアップグレードするコストは非常に高価です。同じサーバーを同じ価格で複数購入することができます。 ApacheとmysqlがCPUのほとんどを占有しているように見えますが、Apacheはすべてのイメージを処理するため、ここに問題があります。
これが何らかの方法でなければならない理由はありません。両方を最適化すると言います。多数のイメージがある場合は、サーバーで何をするかに関係なく、CDNは理にかなっています。また、それが問題を処理しても、一般にデータベースのパフォーマンスが向上することは役立つため、両方のオプションに取り組むことをお勧めします。
私はAWSツールが大好きです。彼らはあなたが支払うお金のために素晴らしいです、そして、彼らはあなたが使うものだけのために支払います。また、バックアップをダウンロードおよびアップロードするときの接続では、優れたパフォーマンスが得られます。ただし、S3バケットがCDNとして使用されているのを何度か見たことがありますが、他のCDNと同じように機能するようには見えなかったため、さまざまなCDNオプションをテストすることができます。ユーザーがアップロードした画像がたくさんある場合は、何らかのプラグインの統合が必要です。
データベースについては、接続が遅い場合は、インターネット経由で別のデータベースサーバーを使用することはお勧めしません。データベース接続が遅いほど、より多くのリソースが拘束され、ページの読み込みが遅くなります。しかし、それはオプションがないという意味ではありません。別のサーバーを追加できない場合は、SSDドライブを追加することをお勧めします。ドライブがSSDであるかどうかを指定しませんでしたが、そうではないようです。 MySQLは非常にI/Oを集中的に使用する可能性があり、それはまさにSSDが優れていることです。 MySQL専用に使用する別のSSDドライブをマウントして、パフォーマンスを向上させることができます。多くのクライアントが大きな影響を与えるのを見るために、その変更を加えました。
さらに、MySQLインストールを調整します。それは大きな改善をもたらすことができる一般的に忘れられたステップです。ここからツールを選択できます。
https://raw.github.com/major/MySQLTuner-Perl/master/mysqltuner.pl
これを使用するのに役立つ記事を次に示します。
https://www.percona.com/blog/2014/01/28/10-mysql-performance-tuning-settings-after-installation/
WordPressオプションテーブルで過度の一時的なレコードをチェックしても問題はありません。
すべてが言われていることは、これらが問題であると仮定しないでください。ボトルネックがどこにあるかをテストしてください。上記は単なる一般的な推奨事項ですが、問題を知るためにはテストが必要です。まだ行っていない場合は、sysstatをインストールして、使用方法に慣れてください。これにより、CPUが実際に実行していることの詳細がわかります。役立つ記事を次に示します。
http://www.thegeekstuff.com/2011/03/sar-examples/
私はsarを単独で実行し、オプションなしで実行して、私の大きな使用法がどこにあるのかを知るのが好きです。以下は、1週間の使用状況を確認するために使用する個人的な行です。
(sar -u; for d in {1..7} ; do sar -u -f /var/log/sa/sa$(date -d"-$d day" +%d);done)|awk '$4~/20[1-2][0-9]/{d=$4}$9~/[0-9]/{print d" "$0}'|sort -nrk8|sort -nrk10|awk -v t="50" 'BEGIN{n="\033[0m";c="\033[1;31m";w="\033[1;33m"}$10~/[0-9]/{us=$5+$7;io=$8;id=$10;if (us>io){ioc=n;if (us>t){usc=c}else{usc=w}}else{usc=n;if (io>t){ioc=c}else{ioc=w}}printf "%s\tUser/System: %s%4.2f%s\tI/O: %s%4.2f%s\tIdle: %4.2f\n",$1" "$2" "$3,usc,us,n,ioc,io,n,id}'|tail -10
システム/ユーザーとI/Oで使用量を分割します。前者の場合は一般に、PHPスクリプトに対処することで解決される問題であり、後者の場合は、最初にMySQLを見てください。 CPUバウンドだけの場合は、プラグインの削除など、スクリプト自体の最適化に集中します。I/ Oの場合は、iotopをチェックして原因を確認します。純粋にRAMベースの場合（sar -qで確認）、RAMを追加するか、そうでなければ、SSDが役立ちます。もちろん、YMMV。
最初のステップは、サーバーをチェックして、メモリとCPUサイクルによって最も多くのシステムリソースを使用しているものを確認することです。接続の数に応じたMySQLデータベースサーバーは、システムリソースを浪費する可能性があるため、いくつかのことができます...
別のサーバーへのデータベースの転送
これを行うことにより、データベースサービスによって与えられるサーバーの負荷を軽減できます。可能であれば、プロバイダーはクラウドベースのデータベースプラットフォームへの移行を試みます。これは、突発的ではあるが短命のスパイクを処理するためにバースト可能である必要があるためです。画像の転送
S3バケットなどの別のプラットフォームに画像を転送することにより、サーバーへの接続数が減り、システム全体の負荷も軽減されます。
他の人が言ったこと。システムリソースの行き先を確認します。次に、その問題を修正します。持続可能な予算にしたい場合、盲目的に問題に一般的なリソースを投入することはできません。
単一のWordPressサイトがこのように行き詰まっているのは奇妙に感じます。特定のモジュール、または他の人が言及したように、代わりに過度のdb呼び出しが可能です。
ある時点で「localhost」を参照します。これは、パブリックWebサービスの一部であってはなりません。これは、開発目的で直接ログインしたサンドボックスを使用する場合にのみ発生するものです。現在、画像への参照は、すべてが同じサーバー上に存在することを前提としていると思いますか？
注意すべきこと*
Excelシートでプロジェクトに必要な機器やクラウドリソースを計画し、AWSに送信します。彼らはあなたの料金と一致し、おそらくあなたの「費用対効果の高い」計画に一致するようにそれらを低く下げます。必要なのは、メールと電話だけです。さらに、この方法により、プロジェクトの動的に増加するリソースを取得できます。
1秒あたりのリクエスト数はいくつですか？ハードウェアはかなり優れており、単一のWordPressサイトのみをホストしている場合、すべてのサーバーが正しくスケールアウトされる前に、すべてが正しくセットアップされていれば、大量のトラフィックを処理できます。
Apacheは多くのリソースを必要とすると述べました。 nginxへの切り替えを検討してください。私の経験から、これは静的ファイル要求のリソース使用量を大幅に削減し、高負荷の構成が簡単です。
また、最も多くのリソースを使用しているdbクエリも確認する必要があります。