Алексей Сундуков

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

Если из PHP ни чего не возвращает до конца своей работы, то в действие вступает такая настройка как fastcgi_connect_timeout. proxy_read_timeout тут еще не работает (т.к. по сути соединение не считается установленным). Причем максимальная величина fastcgi_connect_timeout - 75 секунд и это величина захаркожена в самом nginx. Поэтому если скрипт должен работать дольше, то нужно из PHP echo-нуть что нибудь.

В robots.txt укажите требуемую скорость обхода сайта.

На основании логов сервера и PTR-ов строить карту IP адресов которые попадают в location с заведомо высоким лимитом.

А второе:

«GET / HTTP/1.0» 499 0 "

явно указывает на причину проблемы. Стартовый nginx закрыл соединение не дождавшийсь ответа от конечного. Нужно просто поднимать таймауты соединений (таких как proxy_send_timeout, proxy_read_timeout и прочие).

Кстати, для дебага очень полезно использовать htop и strace (в htop-е выбрать рабочий процесс nginx-а и нажать S).

Если проксировать на этот же хост — работает. Если на указанный в конфиге — 502.

server_name 127.0.0.1;

Не нужно использовать IP адрес как имя сервера. Следует использовать имена, причем не обязательно существующие. Главное что бы они были в hosts файлах на обоих машинах.

Проблема в регулярно выражении. Должно быть что-то в духе ([a-z0-9-\.]+), а не ([.+]). Текущий же вариант означает "один любой символ и плюс".

Эффективнее это было бы спросить в рассылке. Но на вскидку замечу, что обычно используют встроенный perl.

>Хочу сразу все сделать правильно, и не имея своего опыта
Взаимоисключающе. «Правильно» можно сделать только опираясь на опыт исходя из конкретной задачи. По крайне мере я пока других вариантов не видел.

40 кхитов это немного. Такое даже VPS потянет, хотя при обилии статики может по диску просесть, но тут уж не угадаешь, от соседей тоже зависит. Дедик же даже самой слабой конфигурации переварить не поперхнувшись. И даже в принципе будет большую часть времени простаивать.

С облаком проблема в том, что нужно под свои нужны правильного его настраивать, что бы ресурсы зря не простаивали, но и не тормозило. Засада в том, что пока придешь к оптимальному конфигу придется потратиться, причем явно больше, чем в случае покупки дедика. По крайне мере так получается на практике. Лично я предпочитаю держать дедик и платить фиксированную сумму в месяц, это позволяет точно планировать бюджет.

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

Пожалуй процитирую ответ на подобных вопрос из топика "PHP-FPM на рабочем сервере под Debian 6":

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

К прочтению могу рекомендовать:
«UNIX. Разработка сетевых приложений.» У. Р. Стивенс, Б. Феннер, Э.М. Рудофф
«UNIX. Профессиональное программирование» Стивенс У. Р., Раго С. А. (2-ое издание, посмертное)
«UNIX. Взаимодействие процессов» Стивенс У. Р.
«Ядро Linux» Д. Бовет, М. Чезати

Вообще Стивенс крайне крут, имхо, к прочтению обязательно любому сетевому программисту. Так же могу рекомендовать «выжимку» в том числе и из этих книг от наших авторов: «Операционная система UNIX»
Андрей Робачевский, Сергей Немнюгин, Ольга Стесик.

>Но когда появился большой трафик (примерно 2-3 000 одновременных соединений),
>появилась проблема ошибки 502
php-fpm это не серебряная пуля которая решить данную проблему. Очевидно же, что суть проблем в том, что бэкэнд не успевает переварить такой всплеск нагрузки. Как я понял, при это есть свободные ресурсы, значит нужно крутить настройки сервера.

Увеличте backlog бэкэнда, запросы которые он не сможет принять буду ставиться в очередь. Но увлекаться этим не стоит, пользователь не будет у вас ждать, пока его запрос из backlog будет бэкэндом взят и обработан. Значит смотрите в сторону ускорения приложения. Сколько времени генериться страница? Если ли страницы которые одинаковы для всех? Выносите их в memcached и забирайте самим nginx-ом, не дергайте лишних раз бэкэнд. Включены ли акселераторы в духе XCache? Все ли скрипты при этом в кэше? Как обстоят дела с соединения к базе, сколько по времени они занимаются? Используется ли кэширование на этом уровне? К примеру, у меня в случае забора ответа от СУБД страница в среднем на одном проекте генерится ~15-20 мс, если данные забираются из кэша в роли которого работает Redis, то величина падает до ~2-10 мс, т.е. до 10 раз. И бэкэнд готов обрабатывать следующий запрос.

В общем обращаю внимание, что установка php-fpm чудесным образом ситуацию может не изменить, хотя возможно сгладит её.

С ходу — посмотреть логи.

Конечно может. Как минимум можно в конфиге писать, какие статусы возвращать.

На скидку стоило бы копать в сторону настроек ядра, в частности сетевой подсистемы. Банально netstat-ом посмотреть, сколько соединений висит и в каких состояниях.

Имхо, потому что воркеры-процессы более просты в реализации и более обкатаны по времени. Но логичнее было бы спросить самого Игоря.