Протестируйте лучше сайт чемто более объективным.
Например, хорошая утилита ab, желательно (но не критично) с другого компа в томже ДЦ.
Живо увидите разницу.
Сделал открытие: проксированный через nginx сайт открывается в 4 раза медленней, чем просто через apache. О.О
nginx — 10 requests per second
apache — 46 requests per second
/etc/nginx/proxy.conf?
Хотя чувствую и там всё нормально.
Вообще, можно поставить кеширование, например, на минуту или 10 минут. Тогда к фронтенду обращения будут идти через раз. В случае наличия кук (например, для администратора), кеширование отключать. Тогда будет выигрыш. Имменно 1800 per seconds, у нас VDS держала 3000 в секунду под DDoS благодаря кешированию (ну и GeoIP разумеется но это уже другой разговор).
По поводу выигрыша, попробуйте ab попросить какойнибудь style.css, будет видна разница, особенно если не 5, а 50 запросов в секунду.
Опять к делу.
upstream специально поставлен (другими словами, сервер один или там кластер стоит)? Потому что можно обойтись чуток по другому proxy_pass IP_ADRESS:8080;
proxy_redirect example.com:8080/ /;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
Просто у меня ощущение, что nginx работает прозрачно, кидая поток байт напрямую, а должен запросить апач, дать ему умереть, и медленно отдавать контент.
И в раздел со статикой добавьте
expires 1m;
И ещё
access_log перенесите в корень location (зачем для статики вести логи?)
Если на сайте куча посещений, то первое время пинга косвенно уменьшит за счёт освобожения ресурсов сервера.
Моя вера в незыблемость nginx восстановлена. Устои не разрушены. Можно заснуть спокойно.
А вот поставить expires статике всё-таки не помешает.
Обычно при клике на некую страницу браузер отправляет 30 запросов к картинкам, на каждый из которых сервер отвечает: «не изменилось». При наличии expires браузер не будет ничего спрашивать и сразу брать из кеша (1 минута это нестрашно).
Итого картинки будут грузиться мгновенно и не будет характерного промаргивания.
Если еще кеширование сделать, то и главная будет как электровеник. Но это на любителя.
expires поставил, да. Только не понял как access.log отключить…
Спасибо! Как считаете, 66 запросов в секунду это нормально? Вроде маловато, но апач еще меньше дает.
Это нормально для VPS. Дальше оптимизировать только PHP-часть или (если у Вас ожидается Hi-load на тыщи посещений), включать кеширование.
Можно еще, кстати, настроить PHP-FPM, даст прирост если оперативная память заканчивается. Тоже самое (про оперативную память) можно сделать, настроив PHP как CGI или FastCGI. Во всех трёх случаях перестанут работать .htaccess, команды надо будет при помощи rewrite прописать прямо в конфиге nginx.
Как выше посоветовали, worker_processes 1; в самом начале исправить на 2. Ничего сказать не могу, надо тестировать, всегда считал, что надо ставить равным количеству ядер — в этом случае действительно сильно помогает.
По поводу access_log надо из общей зоны перенести в location.
Сейчас вот так: server {
listen 80;
server_name www.sitename.ru sitename.ru;
access_log /home/user/logs/sitename/nginx_access.log;
error_log /home/user/logs/sitename/nginx_error.log;
location / {
proxy_pass sitename_backend;
include /etc/nginx/proxy.conf;
error_page 404 403 500 = @fallback;
}
А надо так: server {
listen 80;
server_name www.sitename.ru sitename.ru;
location / {
access_log /home/user/logs/sitename/nginx_access.log;
error_log /home/user/logs/sitename/nginx_error.log;
proxy_pass sitename_backend;
include /etc/nginx/proxy.conf;
error_page 404 403 500 = @fallback;
}
Но это мелочи, основной прирост даст правка узких мест в PHP коде и запросах к БД.
По поводу пингов (и только их), бывает когда в сетевой подсистеме ограничено количество внешних (и внутренних сетевых) подключений. В FreeBSD делаются опции ядра, как делается в ubuntu, не знаю. Возможно, nginx довёл количество подключений почти-до-лимита, и подключения на ping не проходили. По этойже причине (всего лишь предположение) перезагрузка помогла — очистились некоторые висячие коннекты.
Ну способов много. И что проверять тоже есть варианты.
В Вашем случае можно, как вариант, взять «webserver stress tool» и померить как сервер держит нагрузку при фиксированном количестве одновременных пользователей, при росте линейном и т.д.
Инструментов много. На Хабре часто проскакивают обсуждения и примеры.
Как минимум цепочка из двух http-серверов, вместо одного, время отклика не уменьшит, а прибавит. А почему случаются эти пики, это уже надо смотреть со стороны сервера, что там в этот момент происходит в системе.
По идее вариант с nginx frontend, apache backend довольно распространенный, проблем быть не должно.
Какую информацию дать с сервера для полной картины? Логи nginx?
nginx debug log в момент пика бы все прояснил, я думаю. Распространенный не значит лучший. Учтите, что как минимум теперь к апачу всегда коннектятся по http/1.0, т. е. без keep-alive. Возможно он теперь раньше и чаще стал убивать свои воркеры. Возможно nginx на чем-нибудь спотыкается. Попробуйте также AIO включить, посмотреть, как изменится ситуация.
