RestAPI: висит запрос (ошибка 503)

[denis79]

Nginx зависает мёртво...

Сделал файл /api/index.php

echo "x";
exit;

После этого обращаюсь к нему:

/api/index.php

$max = 5;
for($i = 0; $i < $max; $i++)
{
    $url = (isset($_SERVER['HTTPS']) ? "https" : "http") . "://$_SERVER[HTTP_HOST]" . "/api/temp";
    $curl_handle =  curl_init();
    curl_setopt($curl_handle, CURLOPT_URL, $url);
    curl_setopt($curl_handle, CURLOPT_SSL_VERIFYPEER, false);
    curl_setopt($curl_handle, CURLOPT_RETURNTRANSFER, 1);
    echo curl_exec($curl_handle);
    curl_close($curl_handle);
}

Если увеличивать $max до 7..10..15 в какой-то момент всё встаёт. И ответ перестаёт приходить.

В реальном коде ведь может быть много разных RestAPI запросов, это вызывает полное засыпание сайта...

Как это можно исправить?

Настройки nginx:

	location /api {			
			rewrite ^/api/(.*)$ /api/index.php?_url=/$1;	
		}		

Крутил и таймауты, и количество соединений и кэши, буфера... Один и тот же результат. При повышение количества запросов - сервер зависает. Использовал разные версии nginx, php... Везде одна и та же картина. При малом количестве запросов - проходит, увеличиваю количество - зависает.

Пока висит nginx, попытка обращаться на другие страницы приводит к ошибке 503.
"Ошибка 503 Сервис временно недоступен Попробуйте через несколько минут..."

[Максим]

Известная проблема, заключается в ошибке конфигурации OSP (нет параметра least_conn;, который немного помог бы) и платная опция queue (что куда более плачевно) в конфигурации Nginx для upstream модуля.

Что касается least_conn;, то его сейчас нельзя добавить в конфиг самому, т.к. список апстримов формируется программой на лету. Это уже исправлено в будущей версии osp находящейся пока в разработке.

Вторая же опция, она платная, точнее работает только в платной версии Nginx. Разработчики Nginx знают о проблеме, о том что в Windows невозможно полноценно работать с PHP в режиме FAST-CGI ввиду отсутствия PHP-FPM. Но по коммерческим причинам не хотят переносить эту опцию из платной версии в бесплатную. Ещё они известны тем, что не любят Windows (по вполне понятным причинам), поэтому в этом направлении Nginx практически никак не развивается.

Ну а чтобы сейчас исправить ситуацию зайдите в настройки OSP в раздел Разное и увеличьте количество потоков PHP на то количество, которое вам нужно (максимальное число одновременных соединений, а точнее это число потоков FAST-CGI). Ставьте число с запасом, хотя бы +5 потоков, но учитывайте что каждый новый поток съедает оперативную память.

[denis79]

Пока выяснил следующее:

1. OpenServer запускает 5 php-cgi.exe для балансировки
2. Я запускаю скрипт /www/test.php ($max = 4)

Всё работает. Мой запрос обработался одним php-cgi, а внутри скрипта запросы распределились по 4-ём другим php-cgi процессам.

Но как только я поставлю $max = 5, процессов php-cgi не хватает, или они висят... Получаю 503.

[denis79]

Известная проблема

Мощно! Большое спасибо, а где про это пишут?
Целый день потратил на поиск вменяемого объяснения.

[Максим]

denis79, на форуме разработчиков обсуждалось. Сейчас гуглом нашел, вот вам цитата:

из того, что столько лет нет подвижек, можно сделать вывод, что
недостаточно мотивации (у кого бы то ни было).

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

Т.е. предлагают их замативировать (деньги) или дописать Nginx самим пользователям (прислать новый код в виде патчей)

Я не против такой позиции, каждый труд должен быть оплачен, но в данном случае Nginx под Windows вообще малопригоден, т.к. полноценно с PHP не работает, только для разработки возможно кое-как пользоваться. Поэтому мне не совсем понятна их позиция по этому вопросу, не вижу проблемы в том, чтобы перенести код из платной версии в бесплатную, что даст возможность полноценно использовать Nginx под Windows.

[denis79]

Чтобы не увеличивать потребление памяти, решил "хакнуть" автогеренарацию для nginx и вместо %streams%... в принципе можно скрипт написать для добавления least_conn.

После этого сразу всё заработало без увелечения кол-ва запущенных процессов.

   #-----------------------------------------------#
    # PHP FastCGI балансировка
    #-----------------------------------------------#

    upstream  backend  {
		least_conn;
		server 127.0.0.1:9000 max_fails=0;
		server 127.0.0.1:9001 max_fails=0;
		server 127.0.0.1:9002 max_fails=0;
		server 127.0.0.1:9003 max_fails=0;
		server 127.0.0.1:9004 max_fails=0;

	}

[denis79]

Т.е. предлагают их замативировать (деньги) или дописать Nginx самим пользователям (прислать новый код в виде патчей)

Ну вообще не должно быть проблемой.

Сказать - вот фича, хотите? Вот копилка, накопите пару тыщ баксов - реализуем. Думаю туча админов и программеров ломанутся к своим тимлидам, чтобы по 30-50 баксов положить в "общаг".

И вопрос решён. Хотя похоже workaround снимает болевое ощущение

[Максим]

В данном случае вы просто удаляете генерацию и вписываете свой конфиг. Так можно конечно, если настройки IP в программе менять не будете. Но least_conn слабо помогает при большой интенсивности запросов, т.е. рано или поздно ваши скрипты всё равно словят 504(502)-ю ошибку. Поэтому без увеличения кол-ва потоков в настройках вы никак не обойдётесь.

[denis79]

Спасибо за совет. Теперь то уже руки чешутся дальше поиграться, мысли уже улетают в другие php-эксперименты.

[Максим]

Т.е. предлагают их замативировать (деньги) или дописать Nginx самим пользователям (прислать новый код в виде патчей)

Ну вообще не должно быть проблемой.

Сказать - вот фича, хотите? Вот копилка, накопите пару тыщ баксов - реализуем. Думаю туча админов и программеров ломануться к своим тимлидам, чтобы по 30-50 баксов положить в "общаг".

И вопрос решён. Хотя похоже workaround снимает болевое ощущение

Боюсь что у них нет такой копилки, более того, разработчики Nginx получили $20 миллионов долларов инвестиций 3 года назад. Да и дело тут не в деньгах, код то уже написан, его можно просто перенести из платной версии в бесплатную, было бы желание.

При работе с Nginx и FastCGI PHP в Windows всегда было 2 недостатка (ввиду отсутствия PHP-FPM в Windows). Первая проблема в том, что нужно ограничивать количество подключений к PHP FastCGI потокам по одному запросу на каждый поток (т.е. 1 поток = 1 запрос, иначе ошибка). Вторая проблема вытекает из первой - нужно собирать остальные запросы к PHP в очередь и выполнять их по мере освобождения потоков FastCGI. Первую проблему удалось побороть в этом году, вот что они сами пишут на Habrahabr: https://habrahabr.ru/company/oleg-bunin/blog/334194/

Научились ограничивать количество соединений с конкретными бэкендами, т.е. для каждого сервера вы теперь можете прописать max_conns, и nginx не будет открывать больше заданного числа соединений к данному бэкенду. Исходно это было сделано для NGINX Plus. Сейчас мы помержили open source просто для того, чтобы сделать людям приятно, с одной стороны, и таскать кастомного кода – с другой.

Т.е. да, они сделали людям приятно и добавили опцию max_conns, но про вторую опцию (queue в upstream), которая так же важна, как эта, они к сожалению забыли Спасибо им и на этом конечно, но было бы логично всё сделать до конца, раз уже дали надежду на нормальную работу с PHP.

Так что пока в Nginx на Windows не появится queue в upstream в дополнение к уже добавленной опции max_conns можно забыть о полноценной работе с FastCGI PHP.