Сервер и его настройка под API?

Question

[Миша]

Всем привет.

Есть следующая задача. Нужно создать API при обращение к которому должен выполняться долгий (от нескольких секунд до 3 минут) PHP скрипт. Во время его выполнения, клиент должен оставаться в режиме ожидания.
Какой сервер использовать в данном случае? Какие настройки выставить?

Пробовал связку nginx + php-fpm, но при большом количестве соединений сервер ожидаемо зависает.

Comments

[hOtRush]

Так все логично, зависает не nginx, а php-fpm, потому что пул забивается висящими соединениями. И apache тут не поможет. Нужно масштабировать сервер(а), но я бы сказал что это в корне неправильно спроектировано, есть же например вебсокеты

[sim3x]

hOtRush, есть тот же лонгпуллинг и EventSource, которые не потребуют внедрения отдельного софта, который будет работать с вебсокетами

[hOtRush]

sim3x, те же лонгполлинг и EventSource без использования ивент лупа так же будут вешать сервер кучей висящих fpm-соединений

Answer 1

[Saboteur]

А почему бы не воспользоваться ajax, и генерировать уникальный ID запроса, передавать его клиенту сразу, затем на стороне клиента крутить анимацию ожидания и периодически дергать сервер по поводу получения инфы готов результат или нет?

Comments

[Миша]

Клиент отправляет GET/POST запрос и ждет результата, без обрыва соединения. Только такое условие задачи.

[Sanes]

Миша, это плохая практика.

[Saboteur]

Миша, Я не верю, что бизнес мог поставить такую задачу - бизнес в этом вообще не шарит.
А техническую задачу - я бы перетер с архитектором, чтобы такую задачу поменять на другой вариант.

[rPman]

Миша, до появления ajax и websocket использовался - javascript pooling, когда веб приложение пытается загрузить javascript файл по запросу

document.write("<scr"+"ipt src='http://server/test_event.php'><\/scr"+"ipt>";
// слово script внутри строки надо скрыть от парсера, помню были браузеры которые иначе на этом глючили

содержимое которого что то типа
event(xxx);
где xxx - собственно данные о произошедшем на сервере событии, сервер же не отдает этот файл сразу а ждет события сам, но по таймауту все равно выдает ответ вида reload() (так же на стороне клиента необходимо ожидать что ответа из-за проблем можно не дождаться и как то корректно это отрабатывать, тем же setInterval проверять, не было ли ответа и повторять запрос, но быть готовым получить ответ сразу от обоих). Т.е. на каждое событие у вас будет вызов javascript функции event(xxx).

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

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

Answer 2

[Sanes]

Потенциально длительные операции надо делать через очереди. Что произойдет при обрыве соединения с клиентом проверяли?
Ответ от API должен быть мгновенным и не ставить клиент в ступор.

Answer 3

[ky0]

Это вопрос к настройке PHP, а на веб-сервера.

Answer 4

[Егор Давыдов]

Возможно говно код, но меня недавно очень спас алгоритм исполнения кода через генерацию Bash скрипта а-ля:

php test1.php &&
php test2.php

При таком виде скрипты обрабатываются одновременно, а количество потоков зависит от процессора сервера