WordPressはどのくらいうまくスケーリングしますか？

1. 共有ホスティングにはあまり期待しないでください.共有ホストを使用している場合は、WordPressの速度が遅いと非難しないでください.共有ホストは、数千のアカウントを1つのサーバーに詰め込む場合があります.したがって、月額$ 10のアカウントを最適化するために一日中過ごすことができ、それは問題ではありません.また、マーケティングの流行語にも注意してください.「クラウド」と表示されているからといって、1台のサーバーを数百人または数千人のユーザーと共有していないわけではありません.

2. 現時点では、キャッシュプラグインは必要ないと思います. WPソースコードを見ると、コアにはすでに高度なキャッシュが組み込まれています.キャッシュのキャッシュキャッシュのキャッシュ-気を付けてください、これは逆効果になる可能性があります.

3. 速度が低下する主な原因はMySQLクエリが遅いことであり、WordPressをすぐに使用しても問題は発生しません.ただし、50,000以上のコメントがあったため、コメントクエリを「制限」する必要がありました. (これはまだ修正されていますか?)また、問題になる可能性のある非定型(数千のカテゴリなど)を実行している場合も問題になる可能性があります.

4. NginXでLinode512を使用しています.「top」は、PHPとNginXがリクエストごとに100分の1秒未満で作業を行っていることを示しています.ほぼすべてのCPU時間はMySQLと結びついています. 20ドルのLinodeで月に100万ページを提供できますが、プラグインと写真の追加を開始したら、「1GB」のLinodeが必要になると思います.私の見解では、それはほぼ直線的です.ページビューが2倍になる場合は、Linodeのサイズを2倍にするだけです.

免責事項:私はLinodeで働いていません.

更新(〜2年後)PHPでページの一部をキャッシュしたいので、これが私が使用する驚くほど高速な簡単なソリューションです. 100分の1秒以内に、ページごとにいくつかの個別のパーツ/部分をキャッシュしています. ramdiskはこれをさらに高速化できるようですが、私のニーズには十分高速です:

 $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;        
} 
 

1. Don't expect much from shared hosting--don't blame WordPress for slowness if you're on a shared host. Shared hosts might cram 1000s of accounts into one server. So you can spend all day optimizing a $10/month account and it won't matter. Also watch out for marketing buzzwords--just because it says "cloud" doesn't mean you're not sharing one server with 100s or 1000s of people.

2. I don't think cache plugins are necessary at this point. If you look at the WP source code, there's already advanced caching baked into the core. A cache of the cache of the cache of the cache--watch out, this can be counterproductive.

3. The main thing slowing you down is slow MySQL queries and WordPress out-of-the-box shouldn't give you trouble here. However, I had to "LIMIT" my comment queries because I had 50,000+ comments. (Is this fixed yet?) Also, if you're doing anything atypical (like 1000s of categories?) that could be a problem too.

4. I use a Linode 512 with NginX and "top" shows PHP and NginX doing their work in less than 1/100th of a second per request. Nearly all the CPU time is tied up with MySQL. You could serve 1 million pages per month with a $20 Linode, but once you start adding plugins and photos, I think you'll need a "1GB" Linode. From my point of view, it's pretty much linear: If pageviews double, just double the size of your Linode.

Disclaimer: I don't work for Linode.

Update (~2 years later) since you want to cache parts of a page with PHP, here's a simple solution that I use that's surprisingly fast. I'm caching several separate parts/portions per page within 1/100th of a second. Seems like a ramdisk could make this even faster but it's plenty fast for my needs:

$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つあり、要約すると次のようになります.

• ホスティングスタック-最新のソフトウェアを備えた優れたホストが必要です-PHP7、Nginx、Varnish、Redis、fail2ban、PerconaDBはすべて適切な選択肢です
• テーブルスキャンはありません-多くのプラグインは、テーブルスキャンが何であるかさえ知らないアマチュアコーダーによって書かれています.テーブルスキャンを回避するには、使用可能なインデックスと、インデックスを使用できるように記述されたクエリの2つが必要です.
• PHPループ内のSQLクエリはないか、ほとんどありません-一部のプラグインコードは明らかに小さなサイトでのみテストされており、何らかの理由でデータベース内のすべての製品をループし、各製品/投稿に対して新しいSQL呼び出しを行います.理想的には、1ページあたり100未満のSQLクエリが必要です-多くのように聞こえますが、実際にはそうではなく、＆lt; 100は、キャッシュされていない約200ミリ秒のTTFBを取得します.

上記を設定したら、キャッシュを追加できます-例:ワニス、CDN、ページキャッシュなど

スケールアウトする必要がある場合は、データベースにPerconaDB XtraDBを使用し、ファイルにUnisonを使用してクラスターを作成できます.そうすれば、1つのノードをwp-adminおよびcronランナーとして使用し、他のノードをロードバランサーの背後でWebトラフィックを処理することができます.

There are ultimately 3 things that slow down WordPress at scale, and they boil down to this:

• Hosting stack - you need a good host with the latest software - PHP 7, Nginx, Varnish, Redis, fail2ban and PerconaDB are all good choices
• No table scans - many plugins are written by amateur coders who do not even know what a table scan is. Two things are needed to avoid table scans - a usable index and a query written in such a way that it can use the index
• No or few SQL queries inside PHP loops - some plugin code has clearly only been tested on tiny sites, and for one reason or another will loop through every product in your database and make a fresh SQL call for each product/post. You ideally want fewer than 100 SQL queries per page - sounds like a lot, but it's not really and with < 100 you will get a TTFB of circa 200ms uncached.

Once you have the above in place, you can then add caching - e.g. Varnish, CDNs, page caching etc.

If you need to scale out, you can create a cluster using PerconaDB XtraDB for the database and Unison for the files. That way, you can have 1 node as your wp-admin and cron runner, and the other nodes serving web traffic behind a load balancer.