Насколько хорошо WordPress масштабируется?

Похоже, что с новым WordPress и его новыми функциями WordPress способен на нечто большее, чем простой движок блога. Но насколько хорошо масштабирование WordPress используется, скажем, 10k -> 100k пользователей в день?

Принимая во внимание то, что многие пользователи будут иметь большую роль в создании хорошей стратегии кэширования, но насколько хорошо WordPress разработан, чтобы помочь, упростить это и дать вам необходимый контроль. Можно ли кэшировать часть страницы и отображать только пользовательские части, поддерживать настройку master / slave db и все такое?

Очевидно, что ничто не масштабируется так же, как статические файлы, обслуживаемые быстрым веб-сервером, и любая CMS, которая должна выяснить, что загружать, а затем загружать, не будет работать так же хорошо, как WordPress или что-то другое. Одна из проблем заключается в количестве запросов к базе данных, необходимых для запроса URL-адреса, и мой опыт работы с предыдущими годами работы исключительно с Drupal и более двух лет с WordPress заключается в том, что WordPress намного лучше в этом отделе.

Тем не менее, почти ничто с любой властью не будет масштабироваться «из коробки» ; это все о том, что вы можете сделать, когда ваши потребности в масштабируемости растут?

На низком уровне «много трафика» есть отличные плагины для кеширования и интеграции с недорогими CDN, которые вы можете сделать довольно неплохо при бюджете без IT и с небольшим бюджетом хостинга. Вот еще несколько вопросов и ответов для обзора:

• Шаги по оптимизации WordPress в отношении нагрузки на сервер?
• Варианты CDN с WordPress Включая плагины поддержки?
• Настройка WordPress для кэширования Amazon CloudFront?

Существуют варианты профилирования для выявления узких мест производительности :

• Профилирование сайта WordPress для развертывания на общем хостинге?

Как только узкие места выявлены, вы можете выполнить локализованную оптимизацию с помощью таких вещей, как Transient API . В этом разделе «Вопросы и ответы» приведен пример, который можно оптимизировать с помощью API Transients, и показано, как:

• Использование WP_Query для запроса нескольких категорий с ограниченным количеством сообщений в категории?

Если вам действительно захочется вытащить большие пушки, вы можете настроить Memcached , HyperDB , Nginx и / или более для ускорения процесса (кажется, что последний действительно превращается в способ получить удивительную масштабируемость из WordPress):

• Включите Memcached для вашего WordPress
• Как ускорить работу WordPress с Nginx и WP Super Cache
• HyperDB
• Nginx в качестве внешнего прокси-кеша для WordPress

И наконец, появляются WordPress-ориентированные веб-хостинги, специализирующиеся на производительности, такие как WP Engine , ZippyKid и другие:

• Лучшие в породе функции высококлассного веб-хостинга WordPress?

Итак, хорошие новости - все весы очень хорошие ; Начиная с самого низкого уровня, бесплатные и легкие, с технической сложностью и стоимостью только растут по мере значительного роста трафика. Начните с WordPress с малого, и это будет здорово. Если ваш трафик действительно растет, и вы даже монетизируете его достаточно хорошо, вы найдете очень эффективный эффект масштабирования по мере необходимости.

По крайней мере, ИМО. :)

1. Не ожидайте многого от общего хостинга - не вините WordPress за медлительность, если вы используете общий хост. Общие хосты могут втиснуть тысячи учетных записей в один сервер. Таким образом, вы можете потратить весь день на оптимизацию аккаунта за 10 долларов в месяц, и это не будет иметь значения. Также следите за модными словечками в маркетинге - просто потому, что в нем говорится, что «облако» не означает, что вы не делите один сервер с сотнями или тысячами людей.

2. Я не думаю, что плагины кеша необходимы в данный момент. Если вы посмотрите на исходный код WP, в ядре уже есть расширенное кэширование. Кеш кеша кеш кеша - следите, это может быть контрпродуктивно.

3. Главное, что вас тормозит - это медленные MySQL запросы, и WordPress из коробки не должен доставлять вам хлопот. Однако мне пришлось «ОГРАНИЧИТЬ» мои запросы на комментарии, потому что у меня было более 50 000 комментариев. (Это уже исправлено?) Кроме того, если вы делаете что-то нетипичное (например, тысячи категорий), это тоже может быть проблемой.

4. Я использую Linode 512 с NginX, а «top» показывает, что PHP и NginX выполняют свою работу менее чем за 1/100 секунды на запрос. Почти все процессорное время связано с MySQL. Вы могли бы обслуживать 1 миллион страниц в месяц с помощью Linode за 20 долларов, но как только вы начнете добавлять плагины и фотографии, я думаю, вам понадобится Linode «1GB». С моей точки зрения, это в значительной степени линейно: если количество просмотров страниц удваивается, просто удвойте размер своего линода.

Отказ от ответственности: я не работаю на Линоде.

Обновление (~ 2 года спустя), поскольку вы хотите кэшировать части страницы с помощью PHP, вот простое решение, которое я использую, которое удивительно быстро. Я кеширую несколько отдельных частей / частей на странице в течение 1/100 секунды. Похоже, виртуальный диск может сделать это еще быстрее, но это достаточно быстро для моих нужд:

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

В конечном счете есть 3 вещи, которые замедляют WordPress в масштабе, и они сводятся к следующему:

• Стек хостинга - вам нужен хороший хост с новейшим программным обеспечением - PHP 7, Nginx, Varnish, Redis, fail2ban и PerconaDB - все это хороший выбор
• Нет сканирования таблицы - многие плагины написаны программистами-любителями, которые даже не знают, что такое сканирование таблицы. Чтобы избежать сканирования таблицы, необходимы две вещи: полезный индекс и запрос, написанный таким образом, чтобы он мог использовать индекс
• Нет или несколько SQL-запросов внутри циклов PHP - некоторый код плагина был явно протестирован только на крошечных сайтах, и по тем или иным причинам будет проходить цикл по каждому продукту в вашей базе данных и делать новый вызов SQL для каждого продукта / публикации. В идеале вам нужно меньше 100 запросов SQL на страницу - звучит как много, но это не совсем так, и при <100 вы получите TTFB около 200 мс без кэширования.

Если у вас есть все вышеперечисленное, вы можете добавить кеширование - например, Varnish, CDN, кеширование страниц и т. Д.

Если вам нужно уменьшить масштаб, вы можете создать кластер, используя PerconaDB XtraDB для базы данных и Unison для файлов. Таким образом, вы можете иметь 1 узел в качестве wp-admin и cron runner, а другие узлы, обслуживающие веб-трафик, за балансировщиком нагрузки.