Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88001
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CANaX5ncSnnkYV0OQp3AD6voV-AuttkR4Sr=9rUPnHLnuZdDndg@mail.gmail.com>
References: <CANaX5ncSnnkYV0OQp3AD6voV-AuttkR4Sr=9rUPnHLnuZdDndg@mail.gmail.com>
Date: Wed, 2 Sep 2015 13:03:43 +0700
Message-ID: <CAEZPtU5rFCeDiX936CGZMRLcUdo0VnyWEKXs8+89tEviR8+Dzw@mail.gmail.com>
To: Davey Shafik <davey@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b676d52e886c1051ebd6dcd
Subject: Re: [PHP-DEV] Add HTTP/2 Multiplexing-related constants to ext/curl
From: pierre.php@gmail.com (Pierre Joye)

--047d7b676d52e886c1051ebd6dcd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

On Sep 2, 2015 12:31 PM, "Davey Shafik" <davey@php.net> wrote:
>
> Hi,
>
> I've been poking around at HTTP/2 a lot lately, and it seems that so long
> as you are using libcurl 7.43.0+ it's possible to do request multiplexing=
.
>
> This change simply introduces three constants, CURLPIPE_NOTHING (0),
> CURLPIPE_HTTP1 (1), and CURLPIPE_MULTIPLEX (2) which represent possible
> values passed into curl_multi_setopt() for the CURLMOPT_PIPELINING option=
.
> Current behavior of passing in 0 and 1 map to the first two constants,
> while the third allows for multiplexing.
>
> Now, of course, being constants, you can just pass in 0, 1, or 2, but thi=
s
> brings the consistency and explicitness of exposing them as with all the
> other curl constants.
>
> I'd love to see this make it into PHP 7.0 if it's not too late? It's
> extremely trivial, but whatever =E2=80=94 not that fussed :)
>
> PR is here: https://github.com/php/php-src/pull/1497
>
> I'm not sure if there is some way to ensure that libcurl is compiled with
> nghttp, but we don't check for the other HTTP/2 stuff so either it's done
> elsewhere and I missed it, or we're making assumptions that the right
> version is enough. Any input on this would be good.
>
> FTR, multiplexing can bring substantial performance improvements,
> especially when factoring in SSL:
>
> 379 HTTP SSL requests
>
> Using HTTP/2 in serial: 63.293796062469 (HTTP/1.1 in serial should be eve=
n
> slower)
> Using HTTP/1.1 with curl_multi: 12.383034944534
> Using HTTP/2 w/multiplexing: 2.7933928966522

I think it should be fine as nothing is changed in the code but the
constants addition.

Let see what the RMs say :)

--047d7b676d52e886c1051ebd6dcd--