В чем смысл асинхронных обещаний Guzzle?

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

$promise = $client->requestAsync('GET', 'http://httpbin.org/get');
$promise->then(
    function (ResponseInterface $res) {
        echo $res->getStatusCode() . "\n";
    },
    function (RequestException $e) {
        echo $e->getMessage() . "\n";
        echo $e->getRequest()->getMethod();
    }
);

Если вы должны вызвать $promise->wait(), чтобы сделать запрос, какой смысл в обещании? Чем это действительно отличается от:

$request = new Request('GET', 'http://httpbin.org/get');
$response = $client->send($request); 

if ($response

Насколько я могу судить, единственным преимуществом является удобный подход к определению обратных вызовов успеха и неудачи запроса. Даже в разделе документации о выполнении нескольких запросов есть приведенный ниже код, который, по-видимому, блокирует и выполняет все запросы... возможно, «в одно и то же время». Это все, что мне следует ожидать?

// Wait on all of the requests to complete.
$results = Promise\unwrap($promises);

person originalbryan    schedule 21.03.2016    source источник
comment
Является ли асинхронность синонимом отложенной обработки?   -  person Jared Farrish    schedule 22.03.2016
comment
Хороший вопрос и, вероятно, нет. На самом деле меня больше смущает часть обещания.   -  person originalbryan    schedule 22.03.2016
comment
Я не верю, что PHP способен к действительно асинхронной обработке событий (пока), отсюда и вызов wait(). Таким образом, может быть некоторая правда, что некоторые из преимуществ, которые вы увидите в Javascript, не очевидны в его версии PHP (пока), но цель обещания состоит в том, что вы можете передать интерфейс только для чтения в отложенные, которые не могут быть разрешены через этот интерфейс. Возможно, это для обратной совместимости (пока).   -  person Jared Farrish    schedule 22.03.2016


Ответы (2)


Я иду на риск, но из того, что я читал...

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

Но допустим, вы хотели загрузить 5 ресурсов. Использование асинхронных методов может позволить этим ресурсам загружаться по существу параллельно, а не только запускать 2-й ресурс после загрузки 1-го.

И Guzzle предоставляет способы обработки вариантов использования, таких как «после того, как все они загрузятся правильно, тогда ...» или «после того, как все они либо загрузятся, либо не сработают ...».

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

person artfulrobot    schedule 21.04.2016

Асинхронность требует немного обратного мышления.

Вот сценарий, который может оказаться полезным: при наличии API (http://ipsum.org/) вы требуется вернуть список данных (по идентификатору) на ваш маршрут (или сценарий). Если вы делаете это процедурно, вам придется перебирать каждый запрос и ждать, пока все не вернется.

С Guzzle Promise вы можете «подготовиться» к ответу, а затем, когда он вернется, вы сможете его обработать. Преимущество этого заключается в том, что вместо N запросов x T времени запроса для выполнения вашего сценария задержка теперь равна CEIL (самое медленное время ответа из всех полученных ответов), поскольку вы «ждете» возвращения ВСЕХ ответов, но они вместо этого отправляется параллельно.

Другими словами, вы отправляете запрос параллельно, а не последовательно, чтобы дождаться ответа на возврат ИЛИ вы можете предварительно выполнить вызов curl, а затем выполнить настройку «хорошо, пока я жду возврата, позвольте мне подготовить ответ».

Более поздняя часть потребует некоторой реструктуризации, поскольку мы привыкли «приносить, ждать, а затем, получив ответ, мы можем работать с ответом».

person azngunit81    schedule 17.05.2016