新しいWordPressとその新機能により、WordPressは単なるブログエンジン以上の機能を備えているようです。しかし、WordPressのスケールは、1日あたり1万人から10万人のユーザーに使用されていますか？
その多くのユーザーにとって、キャッシュストラテジーの大部分は重要ですが、WordPressはこれを支援するためにどれだけうまく開発されているのかを簡単にし、必要な制御を提供します。Fxはページの一部をキャッシュし、ユーザーがカスタマイズした部分のみをレンダリングし、マスター/スレーブdbのセットアップなどをサポートできますか？
回答:
明らかに何もスケールだけでなく、高速なウェブサーバによって提供される静的ファイルをロードし、その後、それは同様に動作しませんWordPressのか、そうでない場合はロードするかを把握する必要がありますし、任意のCMS。問題の1つは、URLリクエストごとに必要なデータベースクエリの数であり、Drupalのみで2年間働いた経験があり、現在WordPressで2年以上経験していることは、WordPressがその部門ではるかに優れていることです。
それは、言ったほとんど何もすべての力を持つが、スケールに行くされていない「アウト・オブ・ボックス」 ; スケーラビリティのニーズが大きくなったときに何ができるのか、ということですか？
「大量のトラフィック」のローエンドには、優れたキャッシングプラグインと安価なCDNとの統合があり、ITの予算とホスティングの予算が少なくてもかなり良い仕事をすることができます。確認する他の質問と回答を次に示します。
パフォーマンスのボトルネックを特定するためのプロファイリングのオプションがあります。
ボトルネックが特定されたら、Transients APIなどを使用してローカライズされた最適化を行うことができます。このQ＆Aでは、Transients APIを使用して最適化できる例を示し、次の方法を示します。
あなたが本当に大きな銃を引き出したい場合は、Memcached、HyperDB、Nginxなどを設定して物事をスピードアップすることができます（後者はWordPressから素晴らしいスケーラビリティを得る方法に本当に進化しているようです）：
そして最後に、WP EngineやZippyKidなど、パフォーマンスに特化した新しいWordPressに特化したWebホストがあります。
だから、良いニュースは、非常にうまくスケールのすべてです。技術的に複雑でコストがかかり、トラフィックが大幅に増加した場合にのみ増加します。WordPressで小さなことから始めれば、それは素晴らしいことです。トラフィックが増加し、それを合理的に収益化している場合、必要に応じてスケーリングすると非常にコスト効果が高くなります。
少なくともIMO。:)
共有ホスティングにはあまり期待しないでください。共有ホストを使用している場合、WordPressの動作が遅いことを非難しないでください。共有ホストは、数千のアカウントを1つのサーバーに詰め込む場合があります。そのため、1日あたり10ドルのアカウントの最適化に費やすことができ、それは重要ではありません。また、マーケティングの流行語にも注意してください。「クラウド」と書かれているからといって、1台のサーバーを数百人または数千人と共有していないわけではありません。
この時点では、キャッシュプラグインは必要ないと思います。WPソースコードを見ると、コアに組み込まれた高度なキャッシュが既にあります。キャッシュのキャッシュのキャッシュ-注意してください、これは逆効果になる可能性があります。
遅くなる主なものは、MySQLクエリの速度が遅く、WordPressをそのまま使用しても問題が発生しないことです。ただし、50,000件以上のコメントがあるため、コメントクエリを「制限」する必要がありました。（これはまだ修正されていますか？）また、（1000のカテゴリのように）非定型なことをしている場合も問題になる可能性があります。
私はLigin 512をNginXで使用し、「top」はPHPとNginXがリクエストごとに100分の1秒未満で作業を行っていることを示しています。ほとんどすべてのCPU時間はMySQLに縛られています。20ドルのLinodeで月に100万ページを提供できますが、プラグインと写真の追加を開始したら、「1GB」のLinodeが必要になると思います。私の観点からは、ほぼ線形です。ページビューが2倍であれば、Linodeのサイズを2倍にするだけです。
免責事項：私はLinodeで働いていません。
PHPでページの一部をキャッシュしたいので（約2年後）更新します。ここでは、驚くほど高速な簡単なソリューションを使用します。1秒の100分の1以内に、ページごとにいくつかの個別のパーツ/部分をキャッシュしています。ラムディスクがこれをさらに高速化できるように思えますが、私のニーズには十分高速です：
$cache_file = "./cache/portion-1". $since; // maybe round() this $since timestamp
$cache_life = 1000; // seconds to keep this cached
$filemtime = filemtime($cache_file); // returns FALSE if file does not exist
if (!$filemtime or (time() - $filemtime >= $cache_life)) {
// heavy lifting starts
$output = 'Heavy!';
// heavy lifting ends
if (!file_put_contents($cache_file,$output,LOCK_EX)) { echo 'error'; } // save the cache
echo $output;
} else {
// load from cache
$output = file_get_contents($cache_file);
echo $output;
} 最終的に、WordPressを大規模に減速させる3つのことがあります。
上記の設定が完了したら、キャッシュ、たとえばニス、CDN、ページキャッシュなどを追加できます。
スケールアウトする必要がある場合は、データベースにPerconaDB XtraDBを使用し、ファイルにUnisonを使用してクラスターを作成できます。そうすれば、1つのノードをwp-adminおよびcronランナーとして使用でき、他のノードはロードバランサーの背後でWebトラフィックを処理できます。