Как стать автором
Обновить

Комментарии 38

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

И спасибо за интересный случай (проверю свой сервер).
Для этого владелец блога должен был почесать репу заранее.
Вобщем, очередное подтверждение того, что скупой платит дважды.
Действительно, это так.
К сожалению, эти действия были сделаны слишком поздно.
Читаю подобные success stories, и всегда не понимаю, ну зачем в этой всей связке apache? Есть же php-fpm, в который прекрасно проксируется всё из nginx и без дополнительной прослойки. Я не говорю что это бы решило проблему, я просто не понимаю — зачем он там?
Объясню: Потому что «из коробки» уставнолен apache. Хорошо еще теперь стали nginx ставить. А как говорится: «Работает? Не трогай.». Именно в критических ситуациях и начинаем все менять. таких как эта. На данный момент, заметной нагрузки нет, и тотальная миграция на php-fpm в очередной раз откладывается. Хотя нутром понимаю, что зря.
У меня была похожая ситуация. Сильно удивило, что сначала проблемой стал Апач, а только потом MySQL. Возможно, можно было и Апач настроить, но php-fpm сразу решил проблему «из коробки»
Частая аргументация — из-за рерайтов\htaccess
Под WP для рерайтов я юзаю такой костыль:

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

Либо пихаем его в location /, либо подсасываем из файла инклудом. Вкупе с плагином nginx Compatibility для самого WP работает на ура. Всё же остальное, что мы юзаем (phpBB, IPB, свои самопальные вещи) работают на ура безо всякой адаптации.
Как бы If is Evil
: )
Не в такой простейшей конструкции :)
Жуткий костыль. Читайте про try files.

+ Зачем велосипед изобретать? Всё описано подробно в мануалах wiki.nginx.org/WordPress и codex.wordpress.org/Nginx
Это было первое, что мне пришло в голову, когда я решил перекинуть генерацию статики на FPM, и когда я увидел, что из коробки не заработало. Спасибо за ссылки, почитаю, переработаю.
Совершенно плевая нагрузка, если честно. Кроме того 6000 онлайн это не 6000 конкурентных или запросов в секунду.

Рекомендую открыть для себя: MaxClients, php-fpm (pm.max_children) и не ронять сервер сервер из-за одного сайта. Так же рекомендую: "56. Подводные камни при использовании кэширования в nginx"
Спасибо. С удовольствием изучу материалы.
Просто у меня ситуацию похожая. На 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".
Еще раз спасибо. Действительно стоит подумать о модернизации уже в ближайшее время.
Интересный материал у Котерова. Добавил в букмарки. Действительно разжеванный конфиг порой сложно найти.
На самом деле можно было переписать правила для WP Super cache из .htaccess в конфиг nginx и оставить все как есть, потому что в результате вы просто перебросили кеширование в nginx, потеряв при этом нужный контроль в WP. И вместо долговременного кэширования с правильным сбросом и по времени и по изменениям вам пришлось делать корткоживущий кэш.
Действительно. Еще один способ, как вариант. Спасибо.
НЛО прилетело и опубликовало эту надпись здесь
статья ни о чем. хотябы назначение директив и методики выбора значений бы расписали. А то больше походит на историю «как я включил кеш на nginx, быстро погуглив»
Спасибо за замечание. Учту.
кроме того вы в глобальном контейнере обьявляете некоторые директивы, а в последующем снова их обьявляете в низлежащих. Непонятно, зачем?

proxy_pass 127.0.0.1:8080;
proxy_cache_valid 200 3m;
Не понял почему так, действительно некоторые секции можно было убрать. Исправил.
Автор говорит на это 2 часа ушло.
Очень хорошие результаты дает кеширование через memcached.
а что кешировать? wordpress умеет юзать memcached?
В комментарии ссылка на плагин, который этому учит.
ухты, спасибо, хоть чтото полезное для себя открыл.
Увидел «CGI»… дальше даже не интересно.
varnish наше все. тоже были проблемы с нагрузкой, после настройки кеширования сайт летает.
1. Mysql cache первым делом должен был быть включен, как так возможно запускать сервер без его включения?

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

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

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

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

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

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

И включить в WP Super Cache Сжимать страницы для єкономии трафика, то можно еще и канал экономить.
Мне стоит, наверное, пристальнее поглядеть в сторону этого плагина. Спасибо.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.