Как вызвать curl и не ждать ответ?

Question

[AlexandrMa]

//Скрипт запуска 1.php

$ch = curl_init();
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, false);
curl_setopt($ch, CURLOPT_URL,  '2.php');
//curl_setopt($ch, CURLOPT_TIMEOUT, 0);
curl_setopt($ch, CURLOPT_TIMEOUT, 10);
curl_exec($ch);
curl_close($ch);
echo '1-ok';

Скрипт вызываемый 2.php

sleep(10);
echo '2-ok';

Вызываемый скрипт 2.php может выполняться долго, а мне надо просто отправить запрос и сразу получить ответ 1-ok Но я скрипт 1 все равно выполняется 10 секунд.

Comments

[Adamos]

Очередь, cron и прекратить колхоз с дерганьем одного скрипта из другого курлом.

[AlexandrMa]

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

[Ипатьев]

Это локальный скрипт или удалённый? Если локальный, то на кой ляд здесь сдался курл и шаманство с ним?

ВОПРОС ЗАДАВАТЬ НАДО ВСЕГДА ПРО ИСХОДНУЮ ПРОБЛЕМУ, а не про свои нелепые попытки её решить.

[AlexandrMa]

Ипатьев, Это входящий хук инициирует. Он обращается к моему серверу. Тот формирует запрос и отправляет обратно. И вот обратный запрос очень долгий. Мне не нужно ждать ответ от него.

[Adamos]

AlexandrMa, курл - не голубиная почта, это двустороннее соединение. Обрыв его на этой стороне вполне может означать, что сделанный запрос не выполнится вовсе. Кто-то должен держать это соединение, пока удаленный сервер не отработает. При использовании PHP curl этот кто-то - как раз твой скрипт.
Хочешь, чтобы он продолжил работу - запускай курл отдельным процессом, а чтобы эти процессы ненароком не наступали друг на друга - таки организуй им очередь. Никакого оверхеда в этом нет.

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

Есть теоретическая возможность, что с заголовком "Connection: close" удаленный сервер быстрее ответит "ну ок, закрывайся, раз тебе не надо", но это зависит уже от реализации на той стороне.

[AlexandrMa]

Adamos, Благодарю за ответ. Всем спасибо, теперь разобрался с вопросом.

Answer 1

[Vitsliputsli]

Типичное решение, как уже описал Adamos, это запуск отдельных процессов через cron (или демоном, если работы много или нужна быстрая реакция), которые разбирают очередь.
Почему не через exec, потому что это структуризация кода, разделение и контроль отдельных процессов, да еще и хороший контроль нагрузки.
Есть еще варианты со своими особенностями:
1) если ответ не нужен (но, только если это действительно так!), то используйте UDP;
2) если это fpm, то отправляйте сперва ответ пользователю через fpm, а потом уже шлите запрос (здесь можно будет проконтролировать ответ и сообщить об ошибке в лог). Т.е. пользователь получит ответ, а ваш запрос отработает после в фоне. Но тогда, вместо отдельных воркеров мы все скидываем на воркеры fpm, так что это тоже надо учитывать.

Answer 2

[toxa82]

Зачем вам curl, если вы хотите вызвать скрипт рядом, попробуйте через exec('/usr/bin/php 2.php > /dev/null 2>&1 &');
, так запускает скрипт и уходит в фон.

Comments

[Adamos]

И если этот второй скрипт будет валиться с ошибкой на первой же секунде, вы об этом узнаете... никогда.
Кстати, попробуйте угадать, какой версии на вот этом хостинге /usr/bin/php:

$ whereis php
php: /usr/bin/php /etc/php /opt/php56/bin/php /opt/php74/bin/php /opt/php73/bin/php /opt/php83/bin/php /opt/php71/bin/php /opt/php53/bin/php /opt/php82/bin/php /opt/php72/bin/php /opt/php80/bin/php /opt/php81/bin/php /opt/php54/bin/php

[toxa82]

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

[Adamos]

toxa82, это не ответ, это предложение такого же костыля, как тот, на котором ему стало неудобно скакать.
Замена говнокода говнокодом.

[toxa82]

А вы уверены что ему надо ваш правильный подход с очередями и кронами? Если у него нет в проекте очередей, то нафиг они ему нужны чтоб какую-то стату заполнить, и убить пару дней на создание инфраструктуры под них. Не у всех высоконагруженный проект. У него конкретный вопрос был, не будет работать мой подход, пусть тогда смотрит в сторону очередей. Не надо усложнять всё сразу.

[Adamos]

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

[toxa82]

Ну да ну да, пусть еще с десяток классов, интрефейсов и трейтов добавит и свяжет это все через пару паттернов. То что надо чтоб запустить скрипт в фоновом режиме.

[Ипатьев]

Он задал совершенно конкретный вопрос, причём с релевантным заголовком. На который гугль будет приводить приводить людей, которые хотят отправить НТТР запрос без ожидания ответа.

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

[toxa82]

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

[Adamos]

Ипатьев, говнокод с exec или односекундным таймаутом гугловская нейросетка выдает выше, чем ссылку на этот вопрос.
Однако сам вопрос, как правило, будет просто следствием ошибки планирования. На что ИИ указать постесняется, а Тостер - нет ;)

[alexalexes]

Я знаю, что PHP - очень плохой дирижер в асинхронщине.
Мне лично интересно, чем плох вариант c функциями curl_multi_*?
Мне гугл это подсовывает на запрос "curl php асинхронный вызов".

[toxa82]

alexalexes, скорее он имеет ввиду несколько одновременных запросов на разные урлы, но ответы вы потом всё равно собираете вместе ниже по коду.

[AlexandrMa]

Ребят, мне достаточно понять, может ли curl выполниться без ожидания ответа, вот и всё.
Если не может, то напишите что это невозможно.
Я в гугле нашел примеры, что это типо возможно.

curl_setopt($ch, CURLOPT_RETURNTRANSFER, false);
curl_setopt($ch, CURLOPT_TIMEOUT, 0);

Но не работает. Все равно curl ожидает ответа. Поэтому, если это анрил, то отбой, конечно.

[Vitsliputsli]

alexalexes,

Я знаю, что PHP - очень плохой дирижер в асинхронщине.
Мне лично интересно, чем плох вариант c функциями curl_multi_*?
Мне гугл это подсовывает на запрос "curl php асинхронный вызов".

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

[xsash]

AlexandrMa, в вашем примерее задается минимальный таймаут (0), по которому прерывается соединение

вот полнее вариант, но за 1-2 мс запрос может не уйти

$ch = curl_init('https://example.com/test');

curl_setopt_array($ch, [
    CURLOPT_POST            => true,
    CURLOPT_POSTFIELDS      => json_encode(['event' => 'test']),
    CURLOPT_HTTPHEADER      => ['Content-Type: application/json'],
    CURLOPT_RETURNTRANSFER  => false,   // не ждать тело ответа
    CURLOPT_TIMEOUT_MS      => 1,       // 1 мс
    CURLOPT_CONNECTTIMEOUT_MS => 1,
]);

curl_exec($ch);
curl_close($ch);

либо как писали выше про асинхронный запрос

$mh = curl_multi_init();

$ch = curl_init('https://example.com/test');
curl_setopt_array($ch, [
    CURLOPT_POST => true,
    CURLOPT_POSTFIELDS => json_encode(['event' => 'test']),
    CURLOPT_HTTPHEADER => ['Content-Type: application/json'],
    CURLOPT_RETURNTRANSFER => false,
]);

curl_multi_add_handle($mh, $ch);

// Запускаем, но не ждём
curl_multi_exec($mh, $running);

// Сразу закрываем
curl_multi_remove_handle($mh, $ch);
curl_multi_close($mh);
curl_close($ch);

[Vitsliputsli]

xsash, не рекомендую пользоваться этими вариантами, т.к. они строятся на некорректном использовании протоколов.
Если задача отрабатывает слишком долго, значит фиксируйте получение, а обрабатывайте позже. Если вам не нужен ответ, значит не стоит использовать tcp/http.

И несколько моментов: таймаут = 0 не минимальный, а наоборот бесконечность. CURLOPT_RETURNTRANSFER никак не влияет на ожидание тела ответа. А curl_multi_exec это не запуск отправки, а прерывание для работы асинхронных задач, и для нормальной отправки запроса одного прерывания будет недостаточно.