какую посещаемость выдерживает wordpress
Миллион посетителей на WordPress против сервера
Мой сервер, который и будет героем последующего повествования — это обычный арендованный у FirstDedic сервер среднего класса с процессором DualCore Xeon E3110 3.00Ghz. Оперативной памяти было установлено 4 Гб, жесткий диск 500 Гб. На сервере был установлен nginx 1.01 в качестве frontend, и apache 2 в качестве backend, с запуском скриптов в режиме CGI.
История приключилась с сайтом, который был размещен на моем сервере, собственно, не сайт, а чужой личный блог. Ранее на блоге наблюдались пики трафика до 10000 в сутки, но с подобной нагрузкой сервер справлялся на ура абсолютно без оптимизации на стандартных файлах конфигурации.
И вот, в один прекрасный «Женский день», утром, приходит SMS от сервиса мониторинга сайтов, что сервер недоступен. Естественно, от такой новости мгновенно просыпаюсь, и пробую пинговать сервер. Пинг присутствовал, но очень вялый. Соединение по SSH установить невозможно, потому что все ресурсы сервера отданы неизвестному процессу, или процессам.
Соединившись по KVM, я отправил сервер в перезагрузку, и сразу после загрузки соединился по SSH. В процессах, я увидел страшную картину: запущено около 1000 процессов php от имени автора блога, кроме того, Load averages больше сотни. Очень страшный показатель, который показывает, сколько приходится ожидать процессу своей очереди на порцию ресурсов.
Естественно, времени мне хватило только чтобы это увидеть, запустив команду top. Уже через минуту сервер перестал отвечать на запросы, и пришлось его вновь перезагрузить, и сразу после перезагрузки выключить apache. Теперь я гарантированно получил сервер, который не израсходует все ресурсы. Начал проводить анализ, я вывел число открытых соединений командой netstat и ужаснулся. Было более 10000 установленных соединений с nginx. Это значит, что за последнюю минуту было 10 тысяч попыток зайти на сайт клиента – хорошая нагрузка.
Попытавшись порыться в настройках WordPress, естественно с согласия клиента, Я обнаружил, что был активирован плагин для кэширования WP Super Cache, который я выключил, потому что при выполнении самую большую нагрузку на файловую систему давал именно он. Выключив плагин, сайт стал выполнять очень много запросов в базу данных – неудивительно. Поэтому первым делом я включил систему кэширования запросов в MySQL, так как нагрузку давала всего одна страница, на которую и было множество переходов. После включения кэширования запросов, база данных вздохнула свободнее, но не настолько, насколько хотелось бы, притом, что основную нагрузку теперь давал сам WordPress.
Выключив все возможные плагины и переписав тему с наименьшим количеством запросов, нагрузка не уменьшалась. Пришлось идти на крайние меры — я включил принудительное кэширование проксированных запросов в nginx. Для этого я прописал в секции http следующую строку
В нужную нам секцию server прописываем:
Как только я это сделал, нагрузка на сервер резко упала. Однако мы получили множество неудобств, связанных с администрированием и комментированием. Несмотря на неудобство, проблема была решена. Однако сознание подсказывало, что включать вручную такое кэширование не всегда будет время и возможность, а оставлять как есть не вариант для автора блога. Таким образом, пришлось запрещать кэширование для авторизованных пользователей, и пользователей, оставивших свои комментарии. В итоге получается примерно такая секция server:
После этого неудобства в работе полностью компенсируются бесперебойностью.
Как итог ко всему вышеописанному, сервер был недоступен в течение 2 часов, за это время поток трафика значительно уменьшился, но после этого случая были и другие подобные праздничные всплески посещаемости, которые сайт успешно выдержал, не дав ощутимой нагрузки на сервер. С тех самых пор стараюсь на все размещенные сайты на WordPress ставить такую конфигурацию.
Google Analytics на сайте клиента, после того, как сервер окончательно поднялся, показывал 6000 посетителей онлайн. Эта цифра быстро падала, потому что актуальность запроса, по которому сайт был в топе всех поисковых систем, терялась каждую минуту. К концу дня, количество посетителей стало семизначным, но владелец ресурса до сих пор смотрит на меня волком, потому что цифра могла быть в разы выше, как и его доход.
Используя этот конфиг могу с уверенностью сказать, что сервер переносит несколько подобных сайтов. Так как мой проект после добавления в Google-Новости стал привлекать много трафика, как собственно и с Яндекс-блогов.
WordPress предназначен для большой нагрузки?
Оценить 7 комментариев
А WordPress из коробки покрывает хотя бы 80% задач вашего проекта?
Он не предназначен, но может быть использован.
Игорь Воротнёв: не ) ну тогда все предназначено для большой нагрузки ) какие проблемы, мощности накупить, пока держать не начнет, вот и все дела.
Если для проекта недостаточно голого WP с небольшими доработками, то кому нужно это мученье.
Серверный стек:
— Nginx 1.9.* (на момент написания данного текста)
— PHP 7
— Memcached
— MariaDB 10.1/10.2
А также фришный SSL-сертификат от Let’s Encrypt + HTTP/2 протокол на стороне Nginx.
Плагины на стороне WP:
— Memcached is your friend для объектного кеша
— Fast Full-Page Cache для кеширования если сайт статичный (см. выше)
— WP Super Cache для кеширования если сайт динамичный (см. выше)
Сайт на wordpress woocommerce, какую максимальную нагрузку может выдержать сайт?
Какую нагрузку выдержит сайт, зависит от того какой тарифный план и какого хостера Вы выберете.
Для каталога 50-100+ я бы уже серьёзно задумывался над специальными решениями типа OpenCart, magento, что либо еще.. А если у Вас предполагаются еще и разные способы доставок и оплаты, то и подавно специализированная cms будет больше к месту чем WordPress + WooCommerce.
Сделать можно, в конце концов даже написать самостоятельно, и без WooCommerce (например shop.farminapetfoods.ru) но зачем? Если только потому, что «я знаю WordPress», то для подобного проекта стоит уже задуматься об «пора узнать что-нибудь еще новенького!».
Да WP имеет прозрачную, продуманную, универсальную и легко расширяемую структуру базы, я сам люблю и больше проектов закончил на WP чем на OpenCart, но WP изначально не содержит в себе необходимого функционала для магазина.. часть его лишь приходит с дополнительными плагинами под дополнительный плагин WooCommerce.. И не всегда дополнительные плагины бесплатны, потому что политика такая, вот какой-то магазин (WooCommerce) отдадим, а бантики будем продавать.
Кеширование в опенкарте какое-то есть, и включено со старта, точно не буду утверждать какое оно.. но если покопать файлы кешей, то видно результаты сложных запросов отрендеренные в хтмл, какя то статика.. Ну и за дополнительные деньги рекомендуют более продвинутые плагины. Премиум сектор OpenCart тоже достаточно развит, есть хорошие решения и за деньги..
Если клиенту не критично на чем строить магазин, и если это не продающая страница на 4.5 товара, пытаюсь склонить его к OpenCart.
Все выше сугубо мое личное мнение, никому ничего не доказываю, не убеждаю, просто насколько знаю и могу сравнивать, попытался рассказать почему одежная щетка в качестве щетки для одежды лучше чем зубная в той же области.
Оптимизируем VPS за 5$ (512MB RAM / 1 CPU) так, что сайт на wordpress выдерживает нагрузку в 42,735,587 хитов в день
Когда вы приобретаете сервер VPS с 256MB или 512MB оперативной памяти на борту и лишь часть мощности процессора, то использовать для таких сервисов как MySQL/PHP/Apache настройки по умолчанию является очень плохой идеей. В настоящее время у меня запущено 3 сайта на самом дешевом тарифном плане с 512MB RAM/1 CPU. Не уверен полностью, но посещаемость составляет порядка 5-10 тысяч посетителей в день. Далее я хочу поделиться инструкцией как оптимизировать LAMP используя всего лишь 512 MB и при этом не уходя в swap. Обычно при такой настройки используется 256 – 378Mb памяти и все работает довольно быстро.
Определяем доступную память и активность swap.
Перед началом оптимизации давайте взглянем на количество используемой памяти. Для этого необходимо выполнить следующую команду:
Для того. чтобы посмотреть список запущенных процессов и отсортировать их по использованию памяти, необходимо выполнить вот такую команду:
Настраиваем LAMP сервер для потребления малого количества оперативной памяти. Останавливаем, отключаем ненужные сервисы
Первый и очевидный вопрос, который необходимо задать — это «какие сервисы мне не нужны в использовании?». Недавно, я обнаружил очень удобную утилиту для управления сервисами. Она называется «sysv-rc-conf» и управляет сервисами при помощи псевдографики и флажками. Выгдялит вот так:
Здесь представлен список сервисов, которые я изменил.
Не запускайте X-сервер, выключите все ненужные сервисы и настройте Apache, MySQL, PHP только с базовой необходимой функциональностью.
Apache
Самая большая проблема Apache — это объем оперативной памяти, который он использует. Я буду рассматривать следующие способы ускорения работы и снижения потребления оперативной памяти:
Настроить Apache на использование только наименьшего количество запущенных дочерних процессов
Prefork — это где случается настоящая магия. Это то, где мы говорим Apache генерировать много процессов. По умолчанию выделяется большое количество, что и приводит к потреблению оперативной памяти сервера. Убедитесь, что apache2.conf не настроен для запуска слишком большого количества серверов или имеет множество запасных. Ниже пример:
Также обязательно отрегулируйте параметр «KeepAliveTimeout«, установив значение 10 или 15. На мой взгляд, 15 секунд слишком много, чем маленькой странице требуется для просмотра и короче, чем требуется для длительного просмотра страницы.
Загружайте только самые необходимые модули
Настроенный по умолчанию веб-сервер Apache подгружает слишком много ненужных модулей. Проверить какие модули установлены и включены можно следующей командой:
Ниже представлен список модулей, которые необходимы для работы WordPress.
Вам необходимо закомментировать остальные модули для экономии памяти. Или же вы можете включить/отключить модули через командную строку. Для включения воспользуйтесь командой:
После проделанных манипуляций вам необходимо обязательно перезагрузить веб-сервер Apache:
Уменьшаем журналирование
Если вы хотите добиться максимальной производительности, вам определенно нужно ограничить журналирование. На моем сервере я установил уровень «error» (ошибок). Также, если вам не нужна детальная статистика, вы можете отключить логирование User-Agent или the http-referer.
Меня устраивают такие настройки, ну а вы сами решайте.
Оптимизация MySQL сервера
Тонкая настройка MySQL для использования малого количества оперативной памяти довольно проста.
Далее мы будем рассматривать следующие типы настроек MySQL:
Для оптимизации MySQL нам необходимо отредактировать файл /etc/mysql/my.cnf.
Вещи, которые нам необходимо выключить
Проблемы блокировок табличного уровня заметны только на очень нагруженных серверах. Для обычных же веб-сайтов, MyISAM показывает лучшую производительность на дешевых серверах.
Если вы решили использовать MyISAM таблицы, то вам необходимо добавить следующие строки в конфигурационный файл my.cnf:
Если у вас будут только MyISAM таблицы, вы можете отключить InnoDB движок, тем самым сэкономив оперативную память, добавив лишь одну строку в my.cnf:
Если вы в прошлом использовали InnoDB, то ниже я предоставляю вам скрипт, который автоматически переконвертирует все таблицы InnoDB в MyISAM.
Оптимизируем параметры MySQL сервера
Ниже представлены несколько параметров, которые могут быть отрегулированы с целью ускорения MySQL сервера.
Key buffer size
Это один из самых важных параметров, влияющий на потребление оперативной памяти и производительности, который необходимо оптимизировать. MySQL пытается положить все, что проиндексировано в key buffer, поэтому этот параметр приносит огромную производительность. SQL-запрос будет подан непосредственно из оперативной памяти RAM. Я не могу сказать, какой размер вы должны установить для key buffer, потому что только вы знаете, сколько RAM имеется у вас свободной.
The Query Cache
Если вы делаете одинаковые запросы два раза подряд, то результат помещается в кэш запросов, таким образом mysql не придется делать запрос снова. Если вы собираетесь повышать производительность, то этот параметр может принести огромную пользу, но возрастет потребление памяти. Поэтому вам необходимо установить этот параметр не слишком огромным, но и не слишком маленьким, то есть столько, сколько необходимо вашему веб-сайту.
Ниже приведены три переменные, которые влияют на то, как работает ваш кэш запросов:
Maximum Number of Connections
Это опциональный параметр. Если вы уже ограничили количество процессов apache, то все уже хорошо. Если нет, и вам необходимо обрабатывать тысячи пользователей одновременно, необходимо увеличить значение этого параметра.
The table Cache
Каждый раз вы обращаетесь к таблице, MySQL подгружает ссылку на таблицу как одну запись в кэш таблицы. Это делается для каждого параллельного доступа к таблице, это действительно важно для производительности, незначительно для использования памяти. Вы можете постоянно увеличивать кэш таблицы, но тогда лы упретесь в лимит на количество открытых файлов в вашей операционной системе, так что имейте это в виду. Если установлен слишком маленький кэш таблицы, то mysql будет блевать на вас, вы же не хотите этого.
Ниже приведен корректный my.cnf, который я оптимизировал на моем VPS с самым низким тарифным планом.
Сторонние мастера настройки MySQL
Я нашел Percona, которая предоставляет бесплатную настройку MySQL и помогает выбрать самые лучше возможности MySQL сервера для достижения лучшей производительности, а также сэкономить время, избежать сложных моментов и рисков, которые могут возникнуть при самостоятельной настройке my.cnf.
Мониторинг MySQL сервера
MySQL хранит статистику, которая помогает определить самые лучшие значения для использования. Кроме этого, имеются две удобные утилиты, которые можно использовать для чтения этой статистики и выводить в понятном формате: tuning-primer.sh and mysqltuner.pl.
Эти скрипты позволят мониторить ваш MySQL сервер, и после предоставят подсказку о параметрах, которые необходимо настроить на вашем сервере.
Оптимизация PHP и кэширование
PHP не очень интенсивно использует память, поэтому я не думаю, что нужно сильно беспокоится о потреблении памяти этим процессов, если ваше приложение не нуждается в этом, но даже в случае необходимости оптимизации, значительно уменьшения потребляемой памяти не будет. Но я исследовал и потом нашел несколько настроек для PHP конфигурации, которые уменьшают потребления памяти веб-сервером.
Alternative PHP Cache
Установите PHP Cache, например, такой как, Alternative PHP Cache. PHP cache будет хранить скомпилированные PHP скрипты таким образом, что они будут заново использованы без компиляции и, соответственно, не создадут нагрузку:
Ниже мой сконфигурированный php.ini файл.
Static Cache
Другая вещь, которая может быть хорошей идеей для блога на маленьком сервере — это поставить его перед статическим HTTP-cache, например, Varnish. Что может реально увеличить вашу масштабируемость. Конфигурация Varnish — это отдельная большая статья, требующая, отдельного топика.
Заключение
Я выложил в открытый доступ конфигурацию моего веб-сервера, чтобы доказать, что можно добиться высокой производительности даже от самого дешевого VPS контейнера с 512МБ RAM и 1Ghz CPU. Использую я Ubuntu 12.04 LTS, LAMP, Varnish,APC Cache для размещения 3-х веб-сайтов, сделанных на WordPress (не мультисайтовых) с посещаемостью 10к в день. Давайте взглянем на результаты тестов от Blitz.io:
Как видите, 0,23% пользователей получают Connection Timeout, когда мой веб-сайт имеет 42,735,587 хитов в день (WOW), может можно еще что-то оптимизировать, но я получаю удовольствие от работы моего веб-сервера. Если ты устал от этого руководства или не хочешь делать руками, то можешь воспользоваться такими сервисами, как PuPHPet или Vagrant.
Нагрузка на WordPress?
Вопросы будут и к хостингу (нужен VPS настроенный)
И к Вордпрессу. В ситуации с 300 тыс записей 100% категоричный отказ от встроенных функций ВП. Даже не пытайтесь. Все фильтры писать вручную с оптимизированными запросами в базу. Стараться по максимуму сократить переборы базы, т.к. его meta_query и прочие встроенные фильтры делают многократные бессмысленные переборы таблиц.
О цифрах по опыту
При оптимизированном VPS на 1 ядре + 1 Гб ОЗУ спокойно работают встроенные фильтры ВП (140 тыс записей) + 7 параметров фильтрации. Но при более сложном фильтре, чем простой отбор параметров появились проблемы даже при росте мощностей до 4 ядер + 4 Гб ОЗУ. Тормоза ощутимые, особенно при одновременной пользовательской активности в 150-200 человек. Оптимизировали сложные запросы, сделали их вручную и все вернулось к прежним 1 ядро + 1 Гб ОЗУ.
На сайте с 420 тысячами записей появились проблемы с фильтрами встроенными сразу. Переписали вручную и проблему сняли, для надежности работает на VPS 3 ядра + 2 Гб ОЗУ.
Обязательное использование кэширования запросов, например сервера Memcache. Также использовать встроенное транзитное кэширование ВП. Эти два подхода снимут любую проблему нагрузки на базу и фильтры наполовину.
Переход на php 7.0 в последнее время положительно сказался на работу ВП.