Как отдать ответ клиенту без ожидания завершения скрипта?

Question

[Алексей Денисов]

Подскажите как вернуть ответ клиенту без ожидания завершения скрипта PHP?
После ответа клиенту, требуется сделать запрос на другой сервис и сохранить полученные данные в файл,
но запрос к другому сервису занимает много время, и клиенту приходится ждать пока завершится скрипт,
хотя полученные данные клиенту абсолютно не нужны в данном запросе.

Пробуюflush()но не работает никак, много примеров уже пересмотрел, но не получается.

Сервер NGINX

Comments

[AnswerREST]

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

[pantsarny]

https://www.php.net/manual/en/function.fastcgi-fin...

Answer 1

[Михаил Ливач]

очереди. После ответа клиенту ставите задание в очередь. Воркер забирает задание, делает запрос на другой сервис и всё остальное. Это не так сложно, как может показаться.

Answer 2

[Vitsliputsli]

fastcgi_finish_request

Comments

[rPman]

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

[Vitsliputsli]

rPman,

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

здесь осторожности нужно не более, чем в любых других вариантах. С какого рожна это говнокод? С чего вы взяли, что работающий fpm-воркер это плохо и критично?
Чтобы заявлять, что этот вариант хуже, чем остальные, нужно как минимум понимать, что за операции выполняются в этом куске кода и как именно планируется реализовывать другие варианты. Без этой информации, такие заявления безосновательны.
Давайте подумаем. У автора все работает и его это устраивает, но он хочет ускорить ответ пользователю. Что изменится после применения fastcgi_finish_request? А ничего не изменится, только пользователь будет получать ответ быстрее, а так все тоже, и что в этом плохого?
Смотрим глубже, что будет если выбрать вариант с очередями или отдельным процессом? Минусы: увеличение расходов ресурсов и общее замедление работы. Плюсы: гибкое управление этим куском кода. А точно оно надо это гибкое управление? А точно ли мы готовы жертвовать ресурсами и скоростью для этого?

[rPman]

да я не против, я сам такие решения генерирую, говнокод это не повод для расстройства, просто нужно это держать в голове

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

[Vitsliputsli]

rPman,

да я не против, я сам такие решения генерирую, говнокод это не повод для расстройства, просто нужно это держать в голове

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

я не вижу здесь говнокода.
Скрытых проблем здесь нет, пока мы не знаем точных требований. Загрузить все воркеры можно множеством других способов легко, не вижу почему fastcgi_finish_request здесь должен быть крайним. А при отсутствии нормального мониторинга это рано или поздно произойдет и без этой функции.
Реальные проблемы скорее будут связаны с тяжелой логикой, которую следует вынести из fpm-воркеров на отдельную машину. Именно в отдельной машине смысл, а не просто "тут нада очередь". А вот если тупо обработку очереди запилить на той же машине, то затем упремся в CPU и все ляжет полностью, что гораздо хуже нехватки воркеров, где просто ожидание у отдельных запросов.

[Daemon23RUS]

Vitsliputsli,

Скрытых проблем здесь нет,

Видишь суслика?
— Нет.
— И я не вижу. А он есть!

Поддержу коллегу rPman, он верно заметил, что это так себе решение. Все может лечь гораздо раньше чем мы куда либо упремся. Мы не освобождаем поток, а их количество конечно и определено в конфиге, например сколько раз надо нажать F5 на этой волшебной странице, чтобы уронить полностью весь сайт ?

[Vitsliputsli]

Daemon23RUS,

Видишь суслика?
— Нет.
— И я не вижу. А он есть!
Поддержу коллегу rPman, он верно заметил, что это так себе решение. Все может лечь гораздо раньше чем мы куда либо упремся. Мы не освобождаем поток, а их количество конечно и определено в конфиге, например сколько раз надо нажать F5 на этой волшебной странице, чтобы уронить полностью весь сайт ?

Так почему оно "так себе"? Что конкретно и в честь чего "может лечь гораздо раньше", или это гадание на хрустальном шаре?
Не особождаем воркер? Ну так он на то и воркер, чтобы работать. Кол-во воркеров это какое-то лимитированное число, которые нельзя менять? Чем лучше, если эту же работу будет делать не fpm-воркер, а просто воркер-процесс? Что будет если процессов будет в разы больше чем процессоров? Чем лучше, если вся производительность упадет в пол по CPU, вместо ожидания fpm-воркера для отдельных запросов? Ответьте на эти вопросы, но не в форме "нам с сусликом так кажется", а конкретно.
Повторюсь, не зная что собрались выносить в эти отдельные процессы, можно сделать даже хуже, нельзя категорично заявлять решение, не зная и не понимая процессы, лишь по наитию. Так что, пожалуйста, технические факты, а не это "мне кажется", "плохо", "мне не нравится"...

[Daemon23RUS]

Vitsliputsli, Хорошо, начнем с известных данных от ТС: требуется сделать запрос на другой сервис и сохранить полученные данные в файл, но запрос к другому сервису занимает много время, и клиенту приходится ждать пока завершится скрипт, Пожалуй это и будет основным критерием.
Имеем Nginx и PHP (что наиболее вероятно будет в варианте php-fpm)
max_children в конфиге php-fpm У ТС спрогнозировать сложно, но предположим что у него простой VPS и эффективное значение max_children будет в районе 20-30

- Не особождаем воркер? Ну так он на то и воркер, чтобы работать.
php-fpm воркер для того, чтобы отработать скрипт и отдать контекст клиенту, взять следующий запрос. Одна из немаловажных метрик - время обработки. Чем оно меньше тем меньше воркеров потребуется для нормальной работы сайта при нагрузке (не важно большой или маленькой, это другая история). У ТС воркер будет "спать" ожидая ответ от другого сервиса.

- Кол-во воркеров это какое-то лимитированное число, которые нельзя менять?
Вполне себе изменяемое значение

- Чем лучше, если эту же работу будет делать не fpm-воркер, а просто воркер-процесс?
сторонний процесс не расходует важный ресурс который отвечает за возможность обработать запрос пользователя и показать ему страницу. С fpm-воркер если сторонний сервис упадет, мы набираем 20-30 запросов которые ждут таймаута, а к сайту ТС уже нет доступа получаем HTTP 502, причем для всего сайта в целом.

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

- Чем лучше, если вся производительность упадет в пол по CPU, вместо ожидания fpm-воркера для отдельных запросов?
И здесь мне непонятно почему производительность должна упасть в пол.

У ТС тривиальная задача, получать ответы от удаленного сервиса и сохранять их в файл, один процесс с очередью, асинхронной обработкой этих запросов прекрасно справится. fastcgi_finish_request это потенциальные грабли на которых он по незнанию потом может очень долго скакать не понимая причин HTTP 502

Достаточно обоснованно ?

[Vitsliputsli]

Daemon23RUS, т.е. резюмируя ваш ответ - эта функция грабли, потому что никто не понимает как работает php-fpm, никто не умеет править конфиги, и боится что-либо менять в принципе.
"много время" - это мало говорит об реальном использовании, в зависимости от цифр "мало" и других параметров нагрузки (кол-ве одновременных подключений и т.п.), в зависимости от необходимой скорости обработки и допустимости ожидания решение будет разным. Возможно у "ТС тривиальная задача", и возможно лучше всего подойдет "один процесс с очередью", но даже если так, fastcgi_finish_request не становится говнокодом или граблями из-за страха и непонимания как все работает. Это разные инструменты с разными плюсами и минусами.
1 процесс с очередью, асинхронной обработкой - прекрасное решение для множества запросов, особенно если они реально долгие и отправлять мнгновенно их не нужно. Кроме одного: нужно сделать очередь (либо поднять брокер, либо дополнительная нагрузка на БД), и сделать асинхронный обработчик в php (что нетипично для php, пусть даже это будет multicurl), т.е. это не считаете сложным и возможность ошибиться здесь исключена? а банально выставить серверу необходимые лимиты это нерешаемая задача?

[Daemon23RUS]

Vitsliputsli, Сама по себе функция fastcgi_finish_request ни какие не грабли, использование ее в кейсе ТС вот это грабли. Признак говнокода - то, что сайт можно уронить жмакая F5 на странице. Все, точка. В кейсе ТС плюс минус так и будет. Количество запросов до падения сайта зависит от фаз луны (доступности стороннего сервиса и времени его ответа) - тоже признак говнокода. При все при этом fastcgi_finish_request ну никак на это не влияет, она дает мнимое ощущение что проблема решена. На что rPman Вам и указал. Даже больше, при использовании fastcgi_finish_request для того чтобы уронить сайт не надо жмакать F5 достаточно просто по нему шарится, ведь теперь клиент не ожидает завершения потока, а порождает новые в процессе навигации.

[Маркус Кейн]

У ТС в статусе "юный программист", и по его вопросам видно, что он еле ориентируется в базовых вещах. Он не знает ни про fpm-воркеры, ни про max_children, ни про то, как сервер ляжет от нескольких параллельных долгих запросов.
fastcgi_finish_request - нормальный инструмент, но не для новичка без понимания инфраструктуры. В его руках это просто способ случайно положить весь сайт, и очень быстро. А ты советуешь его вслепую, даже не зная нагрузку и конфиги.
Так что да - в такой ситуации это плохой совет. Не потому что функция плохая, а потому что ты предлагаешь мину человеку, который точно не знает, как с ней обращаться.

[Vitsliputsli]

Daemon23RUS, Маркус Кейн,
Ну наконец-то! Все же не говнокод и не грабли, а нормальный инструмент. Хоть с этим разобрались.

Другой вопрос, применимо ли это здесь. Я точно не знаю. Но вы почему-то уверены, что всяк другое будет лучше.
Давайте прикинем. "Юный программист", который, как вы считаете, не знает как работает php-fpm, не мониторит работу серверов и настраивает сервисы наугад. Для него fastcgi_finish_request плохо, потому что при повышении нагрузки часть запросов к fpm станет в очередь или вообще отобьется (кстати, не факт, что это плохо). И как мы починим эту возможную проблему будущего? - подключим брокер-очередей, будем писать в очередь и контролировать ее, будем разбирать очередь отдельным демоном, да еще и в асинхронном режиме на пыхе. И тут видно ктото резко забыл про "юного программиста" и нарисовал ему вместо возможной проблемы в будущем, вполне реальную уже здесь и сейчас. Я уж молчу, как непринужденно закатили в архитектуру дополнительную точку отказа, в работе с которой ошибаются и опытные разработчики, и которую, неожиданно, тоже надо конфигурировать и тоже мониторить ее работу.
Тогда еще раз задам вопрос: Почему вы это не считаете сложным и возможность ошибиться здесь исключена?

[Daemon23RUS]

Vitsliputsli, Ну наконец-то! Все же не говнокод и не грабли, а нормальный инструмент. Хоть с этим разобрались.
fastcgi_finish_request перед долгим запросом к стороннему серверу - говнокод.
rPman, красиво все сразу расписал:

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

Вам же захотелось технических деталей. Вы получили. Ну теперь потрудитесь привести доводы, почему Вы топите за решение имеющее проблему: при использовании fastcgi_finish_request для того чтобы уронить сайт не надо жмакать F5 достаточно просто по нему шарится, ведь теперь клиент не ожидает завершения потока, а порождает новые в процессе навигации.

[Маркус Кейн]

Vitsliputsli,

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

cron, php-cli, таблица заданий в БД - элементарная задача для юного погромиста, куча примеров в интернете. FPM не лезет - сайт жив.

[Vitsliputsli]

Daemon23RUS,

Вам же захотелось технических деталей. Вы получили. Ну теперь потрудитесь привести доводы, почему Вы топите за решение имеющее проблему: при использовании fastcgi_finish_request для того чтобы уронить сайт не надо жмакать F5 достаточно просто по нему шарится, ведь теперь клиент не ожидает завершения потока, а порождает новые в процессе навигации.

Не топлю, перечитайте, что я пишу внимательно. Еще раз:
1) fastcgi_finish_request это просто инструмент (с этим, вроде, решили, хотя и не быстро).
2) без понимания, что конкретно происходит, я точно не могу предложить однозначное решение, и я писал об этом выше. Но, вот вы почемуто категорично уверены в своем решении (вернее не в своем, а в том что не подходит).
А основывается ваше решение на "наиболее вероятно", "предположим что у него простой VPS". Почему вы категорично уверены, хотя архитектуру строили на гадании с хрустальным шаром?

fastcgi_finish_request перед долгим запросом к стороннему серверу - говнокод.

У автора "требуется сделать запрос на другой сервис" - другой сервис это может быть реально сервис, и может быть прям локально.
Все ваши заявления это гадания исходя из привычной вам картины и надежды, что она совпадает с картиной пользователя. Разработка основанная на таком - это классический жопа "как написано в ТЗ так и сделал и пофиг что вы там имели ввиду".

[Vitsliputsli]

Маркус Кейн,

cron, php-cli, таблица заданий в БД - элементарная задача для юного погромиста, куча примеров в интернете. FPM не лезет - сайт жив.

Круть, а как вдруг "процесс с очередью, асинхронной обработкой" превратился в последовательную обработку время от времени? Почему когда я указываю на недостатки заявленного "единственно" правильного решения, то резко появлятся другое? Что автору то брать? Или если у него будут проблемы, вы скажете, а ну ты не так сделал, я тут не при делах.
"куча примеров в интернете"? Согласен, в интернете куча примеров реального говнокода. "Cron"? Т.е. мы не сразу отправляем запрос, а там через минутку, а то и позже. Пофиг что там надо, главное у вас сошлось, так?
Ну ок, допустим "юный программист" реализовал эту схему, поправил ошибки и она работает. Применим вами предложенный тест-кейс, пошлем множество запросов, что будет? Правильно, таблица в базе разрастется и все ляжет на фиг и даже снятие нагрузки уже не поможет. А что было бы если автор не впилил эту вашу схему? Правильно, обработка запросов шла как и прежде, но лишние бы подвисли и получили отказ, но если бы убрать эту нагрузку все сразу же заработало быстро.
Т.е. вы предлагаете автору, впилить схему (причем какую точно неизвестно) взяв код из говнокода в интернете, потратить на это время, поймать ошибки, поправить их, и в итоге, это решит лишь проблему которую вам нравится решать (на самом деле вариант одной и той же проблемы), но породит другие проблемы, о которых вам думать не хочется.

[Daemon23RUS]

Vitsliputsli, у автора запрос к другому сервису занимает много время
Исходя из этого: fastcgi_finish_request перед долгим запросом к стороннему серверу - говнокод.
Дальнейший разбор, как и гадания не имели смысла. Абсолютно не имеет значения какой конфиг VPS и сколько памяти. fastcgi_finish_request путь к падению сайта в целом с HTTP 502 . Можно, но не оптимально.
ТС нужно решение проблемы долгой отдачи страницы пользователю. Ваше не решает, а маскирует ее. В частных случаях оно может вполне оправдано, но вот в общем случае - это плохое решение.
Напомню Вам с чего началось обсуждение: с комментария рекомендуется пользоваться этим с осторожностью Вы же утверждаете, что осторожность тут излишняя.
ТС для решения задачи надо внести изменения в свой код. Какие ? Тут есть варианты, и в известных исходных условиях fastcgi_finish_request бомба которая может разнести (постоянно ронять) его сайт. Если это не говнокод, то что это ?

[Vitsliputsli]

Daemon23RUS,

Дальнейший разбор, как и гадания не имели смысла. Абсолютно не имеет значения какой конфиг VPS и сколько памяти. fastcgi_finish_request путь к падению сайта в целом с HTTP 502 . Можно, но не оптимально.
ТС нужно решение проблемы долгой отдачи страницы пользователю. Ваше не решает, а маскирует ее. В частных случаях оно может вполне оправдано, но вот в общем случае - это плохое решение.

Маскирует значит. А когда мы задачу убрали из fpm в "очередь" и оно завалится гдето в базе или гдето в кроновой задаче, это не маскировали?
То, что сайтик отвечает, забирает задачу, а потом ничего не происходит, это значит, что сайтик не работает. Пользователю важен функционал, а не какие коды плавают по http-протоколу. Поэтому, пока мы не знаем флоу или хотя бы важности отдельных модулей, все вами написанное лишь гадание исходя из своего понимания "сайтика" (который на поверку может оказаться и не сайтиком).

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

Да хрена с два я такое утверждал. А писал я следующее: "здесь осторожности нужно не более, чем в любых других вариантах". И об этом, пишу выше, где крутые неговнокодные варианты, где осторожность не нужна, могут расхерачить все и вся почище страшного fastcgi_finish_request.

ТС для решения задачи надо внести изменения в свой код. Какие ? Тут есть варианты, и в известных исходных условиях fastcgi_finish_request бомба которая может разнести (постоянно ронять) его сайт. Если это не говнокод, то что это ?

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

[Daemon23RUS]

Vitsliputsli,

Маскирует значит. А когда мы задачу убрали из fpm в "очередь" и оно завалится гдето в базе или гдето в кроновой задаче, это не маскировали?

Вы реально не понимаете в чем проблема fpm с долгим временем исполнения? Вот это, на мой взгляд, очень опасная привычка для разработчика.

[Vitsliputsli]

Daemon23RUS,

Вы реально не понимаете в чем проблема fpm с долгим временем исполнения? Вот это, на мой взгляд, очень опасная привычка для разработчика.

Понимаю, вы считаете, что все важное и нужное крутится только в fpm, главное чтобы http вернул 2xx, а как работает функционал неважно. Те, замел мусор под ковер, и как бы норм.
Когда надоест жонглировать словами, там сверху есть примеры сравнения плюсов и минусов, критику лучше к ним применить.

[Маркус Кейн]

Vitsliputsli,
Мы вообще не знаем, что ТС делает с этим файлом дальше. Есть вопрос - есть рабочий вариант решения. Если что-то пойдёт не так - спросит ещё, это нормально. Никто не предлагал копировать говнокод, это ты сам придумал. Юный погромист - не значит идиот, схема cron+таблица - простая и распространённая практика.
Пугалка про "таблица разрастётся и всё ляжет" - из воздуха. Записи чистятся, задания берутся пачками, никаких трагедий. А вот твой fastcgi_finish_request - как раз путь к 502, пляскам с fpm и серверной оптимизацией, что для новичка сложнее в разы.
Кроны, очереди и планировщики - нормальный архитектурный выбор. Не нравится тебе - ок, но не надо делать вид, что всё остальное автоматически "плохо".

[Vitsliputsli]

Маркус Кейн,

Мы вообще не знаем, что ТС делает с этим файлом дальше. Есть вопрос - есть рабочий вариант решения. Если что-то пойдёт не так - спросит ещё, это нормально.
...
Не нравится тебе - ок, но не надо делать вид, что всё остальное автоматически "плохо".

Отличные выводы. Именно об этом я все время здесь и писал.

[Vitsliputsli]

Маркус Кейн,

Никто не предлагал копировать говнокод, это ты сам придумал. Юный погромист - не значит идиот, схема cron+таблица - простая и распространённая практика.
Пугалка про "таблица разрастётся и всё ляжет" - из воздуха. Записи чистятся, задания берутся пачками, никаких трагедий. А вот твой fastcgi_finish_request - как раз путь к 502, пляскам с fpm и серверной оптимизацией, что для новичка сложнее в разы..

Не предлагал, но решение "пойди туда, незнаю куда, найди то, незнаю что" несет в себе огромные риски.
"Пугалка из воздуха": вы лечите ситуацию, когда задачи в fpm-воркерах выполняются так долго, что воркеры не успевают освободится для новых задач. Ваше решение - вместо нескольких fpm-воркеров использовать 1 работающий последовательно. Если fpm-воркеров 20 штук, то за 1 сек они выполнят 20 1-секундных заданий, а ваша схема за 1 секунду сделает только 1/20 часть этой работы. Т.е. результат немного предсказуем.
"пляскам с fpm и серверной оптимизацией" - это одно число в конфиге, и не факт что вообще чтото нужно менять, если прочитать сравнение выше.

[Daemon23RUS]

Vitsliputsli,

Если fpm-воркеров 20 штук, то за 1 сек они выполнят 20 1-секундных заданий, а ваша схема за 1 секунду сделает только 1/20 часть этой работы. Т.е. результат немного предсказуем.
"пляскам с fpm и серверной оптимизацией" - это одно число в конфиге, и не факт что вообще чтото нужно менять, если прочитать сравнение выше.

Бинго, Вы показали верхушку айсберга, если сторонний сервер выдает ответ через 5-10 секунд, тогда что ? Роняем сервер ?
Но и это все мелочи, мы не знаем есть ли у клиента сессия, 50/50 но скорее да чем нет. Сюрприз, клиент ответ то получил, а что будет с его новым запросом ? Надеюсь Вы помните что он будет блокирован пока воркер закончит обработку. Ведь Вы не сообщили ТС, что если у него сессия то он должен еще и session_write_close() вызвать.
А если скрипт что то отправит пользователю после вызоваfastcgi_finish_request ?
Помните/знаете ? Воркер определит что пользователь закрыл соединение, и прервет скрипт. Ведь он так устроен это его одно из основных свойств. Вы же и про ignore_user_abort(true) ничего не указали.
И это все для новичка. Вам коллеги пытаются донести что решение то рабочее, но плохое и использовать надо с осторожностью (имея уже достаточно большой опыт и знания за плечами)

Куда мир катится, я уже и не удивлен, не Вы писали калькулятор ?

[Vitsliputsli]

Daemon23RUS,

Бинго, Вы показали верхушку айсберга, если сторонний сервер выдает ответ через 5-10 секунд, тогда что ? Роняем сервер ?

Тогда математика, поменяй в формуле 1 сек на 5-10 и пересчитай, и, неожиданно, та же 1/20 часть.

Но и это все мелочи, мы не знаем есть ли у клиента сессия, 50/50 но скорее да чем нет. Сюрприз, клиент ответ то получил, а что будет с его новым запросом ? Надеюсь Вы помните что он будет блокирован пока воркер закончит обработку. Ведь Вы не сообщили ТС, что если у него сессия то он должен еще и session_write_close() вызвать.

Мелочи? Ну да, предложить вариант в 20 раз хуже, продемонстрировать отсутствие знаний в арифметике, и сразу же слиться "ой, не будем на этом заострять внимание".

Не знаем. Именно, не знаем, так откуда ты взял все эти предположения? Опять хрустальный шар? Чтото он подсказывает только то, что тебе же удобно.
Как наваять "юному программисту" ("не значит идиот") схему о которой вы сами договориться не можете, это без проблем. А как другой вариант - то он вдруг разучился работать с сессиями (или это ты не знаешь как с ними работать?). Но, если придумывать лишь удобное для нужного варианта, то предположим, что у него запрещен запуск cli, и "сюрприз"... А че нет-то? Тебя ж не остановить в придумывании на ходу не относящихся к делу заморочек.

А если скрипт что то отправит пользователю после вызоваfastcgi_finish_request ?
Помните/знаете ? Воркер определит что пользователь закрыл соединение, и прервет скрипт. Ведь он так устроен это его одно из основных свойств. Вы же и про ignore_user_abort(true) ничего не указали.
И это все для новичка. Вам коллеги пытаются донести что решение то рабочее, но плохое и использовать надо с осторожностью (имея уже достаточно большой опыт и знания за плечами)
Куда мир катится, я уже и не удивлен, не Вы писали калькулятор ?

Отлично! Значит наш разговор не прошел даром, и ты уже начал изучать незнакомые инструменты, которых боялся. Что ж, отвечю: если чтото отправит, то ничего страшного не произойдет. По остальному - нет, все не так, когда гуглишь, проверяй что нагуглил, там про другое.
Вам, коллеги, я пытаюсь донести, что решение рабочее, как и другие решения. Какое лучше подходит без дополнительной информации сказать наверняка нельзя. И, конечно, осторожность нужна, как и в других решениях (как выше я разобрал).
А насчет хамства - не удивил. Здесь много таких же, кто некомпетентность пытается спрятать за хамством. Как и у тебя получается плохо.

[Маркус Кейн]

Vitsliputsli, Слушай, здесь уже не обсуждение решения, а чистый спор ради спора. Ты перескакиваешь с тезиса на тезис, подменяешь вводные, притягиваешь фантазии про сессии, "20 раз хуже", "запрет cli" - лишь бы продолжать тянуть эристику.
Мы отвечаем по факту вопроса ТС, а не строим гипотетическую Вселенную, где всё ломается ровно там, где тебе удобно для аргумента. Cron+таблица - нормальная и простая схема; fastcgi_finish_request - нормальный инструмент в определённых условиях. Всё.
А дальше начинается только твоё упёртое "докажите мне, что я не прав", и оно вообще никому не надо.

moderator, тут обсуждение решения переросло в эристическую полемику и перестало быть конструктивным.

[Vitsliputsli]

Маркус Кейн,

Vitsliputsli, Слушай, здесь уже не обсуждение решения, а чистый спор ради спора. Ты перескакиваешь с тезиса на тезис, подменяешь вводные, притягиваешь фантазии про сессии, "20 раз хуже", "запрет cli" - лишь бы продолжать тянуть эристику.
Мы отвечаем по факту вопроса ТС, а не строим гипотетическую Вселенную, где всё ломается ровно там, где тебе удобно для аргумента. Cron+таблица - нормальная и простая схема; fastcgi_finish_request - нормальный инструмент в определённых условиях. Всё.
А дальше начинается только твоё упёртое "докажите мне, что я не прав", и оно вообще никому не надо.

moderator, тут обсуждение решения переросло в эристическую полемику и перестало быть конструктивным

ты адресатом ошибся. Про перескакивания, фантазии про сессии, построение своей удобной Вселенной, это вон к Daemon23RUS.
Техническая аргументация выше, но ты, как и Daemon23RUS, упорно ее игнорируете.
Разве что "20 раз хуже" мое, ну так ответь, как замена 20 воркеров на 1 с последовательной обработкой, по твоему плану, сможет решить проблему множества запросов?
Я не просил доказать, что я не прав, но вы вдвоем пришли и бросились доказывать, а когда не получилось, один начал хамить, второй пошел звать папку. Посмотри на rPman, высказал свое мнение, я свое, не сошлись, но не беда, как адекватный человек, он пошел дальше.

Answer 3

[ThunderCat]

Кроме очередей, как написал Михаил Ливач есть вариант запуска cli скрипта в отдельном потоке и завершить скрипт.

Answer 4

[Евгений Обыкновенный]

function echo_and_close( $str = '' ) {
  ob_start();
  ob_clean();
  echo($str);
  header($_SERVER['SERVER_PROTOCOL'].' 200 OK');
  header('Content-Length: '.ob_get_length());
  header('Connection: close');
  ob_flush(); 
  flush(); 
}

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

php_value output_buffering 0
SetEnv no-gzip 1