Req #71832 [Opn->Sus]: Support for persistent connections

Edit report at https://bugs.php.net/bug.php?id=71832&edit=1 ID: 71832 Updated by: cmb@php.net Reported by: rmoisto at gmail dot com Summary: Support for persistent connections -Status: Open +Status: Suspended Type: Feature/Change Request Package: cURL related PHP Version: Irrelevant Block user comment: N Private report: N New Comment: > The same feature already exists in PDO (PDO::ATTR_PERSISTENT) > for practically the same reason. And has the known issue that persistent connections are stored per process/thread. I would expect the same when caching cURL handlers, and as such this wouldn't quite as efficient as desired. And there are certainly more "details" to be considered/discussed, so this feature needs the RFC process[1]. [1] <https://wiki.php.net/rfc/howto> Previous Comments: ------------------------------------------------------------------------ [2020-10-13 14:08:10] e6990620 at gmail dot com Just chiming in to insist that in general this feature would be very beneficial for PHP systems that act as proxies or API gateways, as they currently have to set up a new connection to the same origin servers again and again for each incoming request. In the worst cases each of these connections involve a DNS lookup, TCP setup and TLS negotation to far away servers before the first byte can be sent. The savings from being able to reuse a pool of these connections between PHP-FPM requests could be massive. For now the only way I know to achieve this is by ditching PHP-FPM altogether and going with a cli-based server such as RoadRunner or ReactPHP (but this introduces its own set of problems, such as likely memory leaks that can bring the application down). The same feature already exists in PDO (PDO::ATTR_PERSISTENT) for practically the same reason. ------------------------------------------------------------------------ [2018-05-15 08:43:14] rmoisto at gmail dot com In the meantime I've found out that DNS is already cached and it's enabled by default. But still, measured by curl request times with a proxy that can hold keepalive connections are anywhere from 100 ms to 800 ms faster. These requests go all over the world in parallel. That proxy however is a pain to maintain and I'm sure doing this directly in PHP would be even faster. ------------------------------------------------------------------------ [2018-02-28 13:51:01] spam2 at rhsoft dot net on a proper system the 4 ms should only hit once, normally you have as local dns-caching resolver on 127.0.0.1 on servers where it matters which eiter does recursion directly or forward to a fast nameserver as near as possible but cache results anyways ------------------------------------------------------------------------ [2018-02-28 13:06:30] rmoisto at gmail dot com I'm not sure where I got that 60 ms from. Currently curl is reporting connection time to another server on the local network as 5 ms. 4 ms of that is name lookup. The total request time is 6 ms. It would already be a bonus if curl didn't query the name server each time and cached the results for a bit. Keeping a persistent connection would be even better. ------------------------------------------------------------------------ [2018-02-28 12:43:48] spam2 at rhsoft dot net and within the LAN 1.4 ms while we talk here about fetch the whole page and not only connection and with https below 5 ms Concurrency Level: 1 Time taken for tests: 1.349 seconds Complete requests: 1000 Failed requests: 0 Total transferred: 4075053 bytes HTML transferred: 3778000 bytes Requests per second: 741.49 [#/sec] (mean) Time per request: 1.349 [ms] (mean) Time per request: 1.349 [ms] (mean, across all concurrent requests) Transfer rate: 2950.78 [Kbytes/sec] received Concurrency Level: 1 Time taken for tests: 4.978 seconds Complete requests: 1000 Failed requests: 0 Total transferred: 4038052 bytes HTML transferred: 3778000 bytes Requests per second: 200.88 [#/sec] (mean) Time per request: 4.978 [ms] (mean) Time per request: 4.978 [ms] (mean, across all concurrent requests) Transfer rate: 792.14 [Kbytes/sec] received ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=71832 -- Edit this bug report at https://bugs.php.net/bug.php?id=71832&edit=1