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

34

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

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

googletorp
источник

Ответы:

37

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

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

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

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

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

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

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

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

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

MikeSchinkel
источник
Спасибо за такой тщательный ответ. Интересно, как работают API-интерфейсы WordPress для кэширования частей страницы - так что вам нужно только генерировать специфичные для пользователя части, а не всю страницу для зарегистрированных пользователей или использования Edge Side Includes для сайтов с высоким трафиком.
googletorp
Майк, ты зверь! Везде, где я захожу на этот сайт, я сталкиваюсь с вашими ответами, и все они великолепны!
dgw
@googletorp : Вы определенно можете это сделать, он просто принимает ручной код. Мне бы хотелось посмотреть, можно ли разработать инфраструктуру, чтобы упростить ее, но в настоящее время я сосредоточен на попытках реализовать надежные и многофункциональные настраиваемые поля сообщений. Возможно, скоро. :) @ Voyagerfan5761 : Спасибо. :)
MikeSchinkel
kiragiannis.com/cloud-computing/… Это может принести некоторые метрики к разговору.
Гео
4
  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;        
} 
PJ Brunet
источник
0

В конечном счете есть 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, а другие узлы, обслуживающие веб-трафик, за балансировщиком нагрузки.

Дейв Хилдич
источник