Помощь Настройка WP и сервера для высокой посещаемости

[mischael1]

Исходные данные:
Дедик (2,0 ГГц (4 ядра, 4 потока), 500 ГБ SATA×2 (RAID1), 6 ГБ RAM) Linux, Apache, MySQL
Контент — видео (на амазоне, youtube, vimeo, т.е. на сервере его нет), фото на серваке
WP + 10 плагинов. Оптимизации WP в эту сторону никакой не проводилось
Сейчас посещаемость под 1К уников/сутки вроде всё ровно, но посещаемость растёт и будет расти.
Я никогда не вел проекты с такой посещаемостью и поэтому переживаю, как бы не обосраться.

Задача:
Определить что именно и как надо настроить при таких параметрах сервака, чтобы сайт мог вывезти максимально серьёзную нагрузку.

Знаю, что есть плагины для настройки кеширования — их много есть ли разница какой из пары самых скачиваемых использовать?
Настройки вордпресса по использованию памяти (memory limit и т.п.) стоит трогать?
Не лучше ли вместо плагина руками внести необходимые настройки (опять же где и какие)?

Ну и просьба для тупых описать. Если не до уровня «нажмите кнопку пуск», то хотя бы с названиями файлов, плагинов и настроек. Спасибо!

 

[dandandan]

По-моему вполне адекватный вопрос от новичка, начинающего разбираться с настройкой сервера.
Сам год назад гуглил аналогичные варианты.
Вариантов два: самому методом проб и ошибок разобраться (долго) или отдать денег и настроят (быстро).

Если самостоятельно разбираться, то нужно смотреть нужно в сторону:

• облачный сервис, автоматически увеличивающий производительность выделенного сервера, но это дорого. Нет смысла рассматривать
  
• кеширование объектов / блоков / целых страниц

Конфиг сервера лучше переделать под nginx + php-fpm вместо апача. Придется переписывать правила modRewrite под nginx.

Кешированием статических объектов занимается nginx, так же ему можно выделить энНое количество места под кеш целых страниц.

Ставим модуль кеширования. Тут самому играться и смотреть какой лучше. Кеш можно хранить на диске. Так же кеш можно хранить в оперативной памяти сервера (для этого нужен memcache или memcached ).

Для себя для ВП я писал свой модуль, который создает полностью статическую страницу. В итоге страница загружается за сотые доли секунды. Кеш устаревает за Х часов и сам обновляется.

В итоге

1. выбросить апач, поставить nginx + phpfpm
2. Крутить настройки nginx
3. Крутить настройки базы mysql (кеши, индексы).
4. Если есть свободная память, то кеш бросать в память memcache, если нет, то на диск
5. Система кеширования страниц. Идеально, если в статическую страницу.

Все остальное зависит от конфига системы.

p.s. Посмотрел конфиг дедика. Настраивал похожий ВПС. Крутится около 20 сайтов ВП. На каждом количество постов от 10 000 до 300 000. База суммарно около 7 гб. Со статическим кешем все летает.

 

[dj_snake]

Кешированием статических объектов занимается nginx, так же ему можно выделить энНое количество места под кеш целых страниц.

Ставим модуль кеширования

Классно..., то есть вы предлагаете кешировать на уровне локейшена нжинкса ответы от бекенда, которые по факту кешируются на уровне самой cms? При всем уважении, но вы тоже путаете что зачем надо... создаете новичку трудности в виде лемпы и её настройки под ВП хоть манов и много...

все же лучше облачный хостинг для него, под хайлоад проекты, хотя я 1000юников на вп не могу назвать серьезной нагрузкой, даже средней... особенно если там нет динамики.

 

[Karlasan]

Классно..., то есть вы предлагаете кешировать на уровне локейшена нжинкса ответы от бекенда, которые по факту кешируются на уровне самой cms?

при кешировании посредством cms она обычно все равно инициализируется - проверяются обновления страниц, делаются какие-то запросы к бд и т.п. это быстрее, чем вообще без кеширования, но медленее, чем отдача чистой статики. dandandan предложил тебе быстрейший вариант из возможных, пусть и самый сложный в реализации. не хватает навыков для его претворения в жизнь - нанимай специалистов и раскошеливайся.
я сам не так давно при оптимизации магазина (на другом движке, но суть работ та же) перепробовал если не все, то многие способы ускорения работы сайта, самый быстрый оказался как раз предложенный dandandan'ом.

 

[dj_snake]

самый быстрый оказался как раз предложенный dandandan'ом.

Очень плохо. Это не самый быстрый, во первых, во вторых очень затратный на ресурсы io жесткого диска, а также ревалидация итп, много подводных камней, это сделано в нжинксе не для этих целей.

Самый быстрый - это локейшн через try где будет попытка открыть заранее закешированную страницу cms и раздать напрямую нжинксом клиенту - в таком случае не будет обращения к php и бд, а вот при обновлении страницы она отлично обновится и ревалидируется, так же не будет лишней нагрузки на хард нжиксом, который не будет как вы советовали кешировать все 200е ответы подряд от цмс. Я не топикстартер, я хостер. Для типичного вордпресса или любой цмс нет метода быстрее раздачи готовой закешированной цмс странички как статическую посредством nginx или varnish. Никакие прокси кеши не нужны в этих случаях, они созданы для других целей, а вы используете проксикешы из-за неумения работать по другому и еще советуете это третим лицам.

 

[Karlasan]

...

что-то я не увидел в своем сообщении всего того, что вы написали. не надо за меня додумывать то, чего я не говорил.

Для типичного вордпресса или любой цмс нет метода быстрее раздачи готовой закешированной цмс странички как статическую посредством nginx или varnish.

далеко не все cms кешируют страницы целиком, а если и делают это - то далеко не со всеми плагинами и далеко не всегда корректно. и вп не исключение. в таких случаях как раз приходится дописывать то, о чем говорил dandandan, я и вы. про "кешировать все 200 ответы" я не сказал ни слова.

 

[dj_snake]

что-то я не увидел в своем сообщении всего того, что вы написали. не надо за меня додумывать то, чего я не говорил.
далеко не все cms кешируют страницы целиком, а если и делают это - то далеко не со всеми плагинами и далеко не всегда корректно. и вп не исключение. в таких случаях как раз приходится дописывать то, о чем говорил dandandan, я и вы. про "кешировать все 200 ответы" я не сказал ни слова.

А нжикс как то кеширует по другому? )) прокси кеш работает по шаблону кеширования (переменные), соотвественно кешируете 200 ответ (успешный) от цмс по url?arg . Повторюсь, метод кеширования нжинксом сделан не для кеширования сайта целиком, исключение - древний скрипт без кеширования с большой нагрузкой который допиливать смысла нет.
про додумывать: есть прицнипы работ и алгоритмы, зачем тут думать. Если ты скажешь что ты ехал на машине, а я сказал что твой двигатель работал - это я додумал или констатировал факт? Просто принципы работы одни, потому я сразу вижу реализацию.

 

[dandandan]

Я написал то, чем пытался пользоваться или пользуюсь. Реально остановился на nginx и создании статической страницы под каждый пост, раскидывающейся в разные папочки. В моем случае - мне хватило. Да, я умею программировать и знаю как переписать плагины под работу из статической страницей. ТС будет проблематично.

Я не топикстартер, я хостер.

Если вы реальный хостер, а не хостер для себя, то наверняка сталкивались с вопросом от юзеров об ускорении работы ВП или других CMS, например на виртуальном хостинге.

Вы же крутите у себя какие-то параметры, вот прямо напишите, что крутите ))). Например, запускаете mysqltuner и выполняете его рекомендации или что-то еще. Не из головы же появляются конфиги.

Специально подписался на тему, чтобы вдруг да найду что-то для себя полезное.

Все известные мне хостеры делятся на 2 типа:

• Просят купить более дорогой тариф
• Дают ссылку на свой мануал или сами что-то подкручивают. На дедике такое уже только за деньги.

Где-то на хабре читал пост про оптимизацию ВП под 10К или 100К посещалку на одноядерном проце и ОЗУ 512 мб. К сожалению, не могу найти
Вот еще несколько постов
Для просмотра ссылки Войди или Зарегистрируйся
Для просмотра ссылки Войди или Зарегистрируйся
Надеюсь, что ТС пригодятся

 

[Karlasan]

А нжикс как то кеширует по другому? )) прокси кеш работает по шаблону кеширования (переменные), соотвественно кешируете 200 ответ (успешный) от цмс по url?arg . Повторюсь, метод кеширования нжинксом сделан не для кеширования сайта целиком, исключение - древний скрипт без кеширования с большой нагрузкой который допиливать смысла нет.
про додумывать: есть прицнипы работ и алгоритмы, зачем тут думать. Если ты скажешь что ты ехал на машине, а я сказал что твой двигатель работал - это я додумал или констатировал факт? Просто принципы работы одни, потому я сразу вижу реализацию.

бро, ты меня не хочешь понимать. я говорил вообще не о том. давай-ка каждый при своем мнении останется, а то мы тут в глухой телефон будем до бана играть.

 

[dj_snake]

Если вы реальный хостер, а не хостер для себя

Да и да))) Боже, как же глупо мой выглядит ответ)) У нас студия автоматизации и разработок, а так же и хостинг как для своих проектов так и для третих лиц. Хостинг закрытого типа, только для юриков или хайлоад проектов.
Конфиги есть готовые написаные нами включая разные мануалы - это не отрицается, но так же много чего собственного в конфах, клиент при регистрации выбирает тариф под свою цмс тк php-fpm, соотвественно для него этот конфиг и ставится, остальные (свои) он можен заинклудить туда. У фронтэндной машины 96гб рамы, бекенды распилены на пачки).
т.к. у нас не хостятся за 100 рублей, есть услуга по настройке конфига индивидуально. Прокси кеш в основном применям для json массивов которые выводятся аяксом, что кешировать на уровне пхп - явно затратно и глупо, потому и сказал конкретно - не для того вы юзаете прокси кеш . с уважением, сорри за оффтоп.
пысы.
тема вообще флудная - размытый вопрос - размытый ответ. Предлагаю зачистить её и все, тольку топикстартеру 0 от всего этого, только w3 total поставил и ему пока этого будет достаточно.

 

[Eduard]

Если сервер не падал, то можно провести оптимизацию на уровне WP:
1) Плагин кеширования (w3, WP supe cashe)
2) Оптимизация и сжатие изображений
3) Оптимизация сжатие и объединение скриптов css, js
4) Асинхронная загрузка js
5) Оптимизация БД

При нормальной пропускной способности нагрузка падет больше на закешированные страницы и их доставку пользователю, так как у Вас контент сторонний больше (так понял из первого поста) и скорее всего функционала, создающего нагрузку на сам вордпресс и сервак не так полно (нужно конечно уточнить наличие ЛК, и количество запросов при загрузке страницы залогиненого пользователя и гостя - но это уже тонкая настройка) то вам вполне хватит внутренней оптимизации проекта чтобы при спокойном потреблении доступных ресурсов обслуживать несколько десятков тысяч пользователей.

Постоянно следите за временем загрузки страницы - в случае роста этого показателя стоит предпринимать последующие шаги к оптимизации.

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