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

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

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

34 голоса | спросил googletorp 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 01 Sep 2010 11:43:21 +0400 2010, 11:43:21

3 ответа


37

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

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

На нижнем конце "большого количества трафика" есть отличные плагины кэширования и с недорогими CDN , вы можете сделать довольно неплохие работу в ИТ-бюджете и низкий бюджет хостинга. Вот еще некоторые вопросы и amp; ответы на отзыв:

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

Как только узкие места идентифицируются, вы можете сделать локализованную оптимизацию с помощью таких как Transients API . Этот Q & amp; A дает пример, который можно оптимизировать с помощью API Transients и показывает, как:

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

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

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

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

ответил MikeSchinkel 1 stEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 01 Sep 2010 13:52:24 +0400 2010, 13:52:24
4
  1. Не ожидайте многого от общего хостинга - не обвиняйте WordPress в медлительности, если вы находитесь на общем хосте. Общие хосты могут переписывать 1000 пользователей на один сервер. Таким образом, вы можете потратить весь день на оптимизацию счета за 10 долларов США в месяц, и это не имеет значения. Также следите за маркетинговыми словами - просто потому, что он говорит, что «облако» не означает, что вы не используете один сервер с 100 или тысячами людей.

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

  3. Главное, что вы замедляете медленные запросы MySQL и WordPress из коробки, не должны вас беспокоить. Однако мне пришлось «LIMIT» мои комментарии, потому что у меня было 50 000 + комментариев. (Это еще исправлено?) Кроме того, если вы делаете что-либо нетипичное (например, 1000 категорий?), Это тоже может быть проблемой.

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

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


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

  $ cache_file = "./cache/portion-1". $ С тех пор; //возможно round () this $ с меткой времени
$ cache_life = 1000; //секунд, чтобы сохранить этот кеш
$ filemtime = filemtime ($ cache_file); //возвращает FALSE, если файл не существует
if (! $ filemtime или (time () - $ filemtime> = $ cache_life)) {

    //начинается тяжелая работа
    $ output = 'Heavy!';
    //тяжелые подъемы

    if (! file_put_contents ($ cache_file, $ output, LOCK_EX)) {echo 'error'; } //сохранение кеша
    echo $ output;

} else {

    //загрузка из кеша
    $ output = file_get_contents ($ cache_file);
    echo $ output;
}
 
ответил PJ Brunet 24 FebruaryEurope/MoscowbThu, 24 Feb 2011 06:24:55 +0300000000amThu, 24 Feb 2011 06:24:55 +030011 2011, 06:24:55
0

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

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

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

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

ответил Dave Hilditch 12 J0000006Europe/Moscow 2017, 21:35:14

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132