fenixru May 9 2012 at 18:50

Миллион посетителей на WordPress против сервера

3 min

21K

WordPress*

From sandbox

+42

Comments 38

masterklass May 9 2012 at 19:06

Но ведь если сделать эти не очень хитрые действия, можно было бы избежать волчьего взгляда автора блога?

И спасибо за интересный случай (проверю свой сервер).

DevMan May 9 2012 at 19:08

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

fenixru May 9 2012 at 19:10

Действительно, это так.
К сожалению, эти действия были сделаны слишком поздно.

slang May 9 2012 at 20:06

Читаю подобные success stories, и всегда не понимаю, ну зачем в этой всей связке apache? Есть же php-fpm, в который прекрасно проксируется всё из nginx и без дополнительной прослойки. Я не говорю что это бы решило проблему, я просто не понимаю — зачем он там?

fenixru May 9 2012 at 20:13

Объясню: Потому что «из коробки» уставнолен apache. Хорошо еще теперь стали nginx ставить. А как говорится: «Работает? Не трогай.». Именно в критических ситуациях и начинаем все менять. таких как эта. На данный момент, заметной нагрузки нет, и тотальная миграция на php-fpm в очередной раз откладывается. Хотя нутром понимаю, что зря.

dmitriid May 9 2012 at 20:18

У меня была похожая ситуация. Сильно удивило, что сначала проблемой стал Апач, а только потом MySQL. Возможно, можно было и Апач настроить, но php-fpm сразу решил проблему «из коробки»

x_T May 9 2012 at 20:18

Частая аргументация — из-за рерайтов\htaccess

ksenobayt May 9 2012 at 22:36

Под WP для рерайтов я юзаю такой костыль:

if (!-e $request_filename) {
rewrite (/|\.php|\.html|\.htm|\.feed|\.pdf|\.raw|/[^.]*)$ /index.php last;
}

Либо пихаем его в location /, либо подсасываем из файла инклудом. Вкупе с плагином nginx Compatibility для самого WP работает на ура. Всё же остальное, что мы юзаем (phpBB, IPB, свои самопальные вещи) работают на ура безо всякой адаптации.

x_T May 9 2012 at 22:52

Как бы If is Evil
: )

ksenobayt May 9 2012 at 22:54

Не в такой простейшей конструкции :)

Amadeusck May 9 2012 at 23:20

Жуткий костыль. Читайте про try files.

+ Зачем велосипед изобретать? Всё описано подробно в мануалах wiki.nginx.org/WordPress и codex.wordpress.org/Nginx

ksenobayt May 9 2012 at 23:22

Это было первое, что мне пришло в голову, когда я решил перекинуть генерацию статики на FPM, и когда я увидел, что из коробки не заработало. Спасибо за ссылки, почитаю, переработаю.

alekciy May 9 2012 at 20:13

Совершенно плевая нагрузка, если честно. Кроме того 6000 онлайн это не 6000 конкурентных или запросов в секунду.

Рекомендую открыть для себя: MaxClients, php-fpm (pm.max_children) и не ронять сервер сервер из-за одного сайта. Так же рекомендую: "56. Подводные камни при использовании кэширования в nginx"

fenixru May 9 2012 at 20:15

Спасибо. С удовольствием изучу материалы.

alekciy May 9 2012 at 20:36

Просто у меня ситуацию похожая. На VPS-ке, не дедике даже еще, кроме своего сайта держал блог друга. Но у меня изначально все на nginx+php-fpm и я его выделил одни рабочий процесс для блога (pm = static, pm.max_children = 1). Потреблял он в простое где-то 20МБ ОЗУ. И тоже к нему раз посетители нагрянули. Что-то под 1500 по статистике гугла. Так это ни то, что сервер уронило, у него на даже на блоге не было ни одной 50х ошибки.

Так что переходите на связку nginx+php-fpm и поймите, что 6000 онайнеров по статистике гугла это мелочи. Вот 1000 в секунду это уже более ощутимо, по крайне мере для WP (ибо я вот на своем PHP движке могу обработать такое количество уложивший в ~300МБ ОЗУ). Кстати лучше ставить стразу 5.4. Как писал вот тут автор у него эта версия показала очень хорошие результаты: "PHP-FPM на рабочем сервере под Debian 6".

fenixru May 9 2012 at 20:40

Еще раз спасибо. Действительно стоит подумать о модернизации уже в ближайшее время.

Londain May 10 2012 at 01:39

Плюс Прозрачное кэширование в nginx для всех и каждого

lehha May 9 2012 at 20:43

Интересный материал у Котерова. Добавил в букмарки. Действительно разжеванный конфиг порой сложно найти.

Wott May 9 2012 at 20:18

На самом деле можно было переписать правила для WP Super cache из .htaccess в конфиг nginx и оставить все как есть, потому что в результате вы просто перебросили кеширование в nginx, потеряв при этом нужный контроль в WP. И вместо долговременного кэширования с правильным сбросом и по времени и по изменениям вам пришлось делать корткоживущий кэш.

fenixru May 10 2012 at 10:22

Действительно. Еще один способ, как вариант. Спасибо.

UFO landed and left these words here

Dzen_Marketing May 9 2012 at 23:35

Такое ощущение что раз в месяц подобные топики постят habrahabr.ru/post/110958/

KiLEX May 10 2012 at 10:00

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

fenixru May 10 2012 at 10:21

Спасибо за замечание. Учту.

KiLEX May 10 2012 at 10:26

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

proxy_pass 127.0.0.1:8080;
proxy_cache_valid 200 3m;

fenixru May 10 2012 at 13:38

Не понял почему так, действительно некоторые секции можно было убрать. Исправил.

Sannis May 10 2012 at 19:01

Автор говорит на это 2 часа ушло.

almirus May 10 2012 at 10:37

Очень хорошие результаты дает кеширование через memcached.

KiLEX May 10 2012 at 12:32

а что кешировать? wordpress умеет юзать memcached?

fenixru May 10 2012 at 13:37

В комментарии ссылка на плагин, который этому учит.

KiLEX May 10 2012 at 13:41

ухты, спасибо, хоть чтото полезное для себя открыл.

Paskal May 10 2012 at 11:09

Конфиг взят отсюда?

alexxxst May 10 2012 at 12:29

Увидел «CGI»… дальше даже не интересно.

mikeSP May 10 2012 at 14:43

varnish наше все. тоже были проблемы с нагрузкой, после настройки кеширования сайт летает.

DjOnline May 12 2012 at 12:32

1. Mysql cache первым делом должен был быть включен, как так возможно запускать сервер без его включения?

2. «Я обнаружил, что был активирован плагин для кэширования WP Super Cache, который я выключил, потому что при выполнении самую большую нагрузку на файловую систему давал именно он.»
Файлы отлично кэшируются в *nix, и тем более если это одна страница, то она всегда находится в кэше файловой системы в памяти и отдаётся мгновенно (а по тестам двухгодовалой давности ещё и быстрее даже чем отдаёт APC). Как может случиться описанная здесь ситуация?

3. Не увидел слова «APC», он включен?

fenixru May 29 2012 at 22:13

1. Исторически сложилось.

2. Не вникал в настройки плагина, не до того было. Возможно был неправильно настроен, но нагрузку давал заметную.

3. Включен.

TIgorA May 16 2012 at 17:56

WP Super Cache отличная вещь, если настроить nginx брать файлы прямо из его папки.
У меня на блоге бывали ситуации, когда php-fpm просто умирал, а nginx продолжал отдавать статику как ни в чем не бывало.
tigors.net/configure-nginx-for-wordpress/

А если скомпилировать nginx с параметром
--with-http_gzip_static_module

И включить в WP Super Cache Сжимать страницы для єкономии трафика, то можно еще и канал экономить.

fenixru May 29 2012 at 22:14

Мне стоит, наверное, пристальнее поглядеть в сторону этого плагина. Спасибо.