---
title: 'Share cURL Handle across PHP Requests (New in PHP 8.5)'
source: 'https://youtube.com/watch?v=wr_Jnrc2has'
video_id: 'wr_Jnrc2has'
date: 2026-08-03
duration_sec: 625
---

# Share cURL Handle across PHP Requests (New in PHP 8.5)

> Source: [Share cURL Handle across PHP Requests (New in PHP 8.5)](https://youtube.com/watch?v=wr_Jnrc2has)

## Summary

This video introduces a new PHP 8.5 API, `curl_share_init_persistent`, which allows sharing connection, DNS, and SSL session data across PHP requests, saving milliseconds per request when communicating with the same hosts. The presenter demonstrates the performance benefits with a real-world example and explains the API's design and usage.

### Key Points

- **Problem: Repeated HTTP setup overhead** [00:02] — HTTP requests to the same hosts waste time on DNS resolution, connection opening, and TLS/SSL handshake in every request. This is especially relevant in cloud/microservice architectures and HTTP-based databases like Elasticsearch.
- **Existing cURL sharing within a request** [01:00] — cURL supports sharing data (cookies, DNS, SSL sessions, connections) across handles within the same PHP request using `curl_share_init` and `curl_share_setopt`. However, this does not persist across requests.
- **Measurable savings: ~5% of request time** [02:12] — Using `curl_getinfo` timers, the presenter estimates that connection and DNS lookup take about 1 millisecond per request, which is roughly 5% of a 20ms request. With SSL, the overhead can be 100-200ms.
- **PHP 8.4 RFC proposal** [03:09] — Eric Norris proposed a persistent cURL share handle RFC for PHP 8.4, which went through two iterations. The second iteration disallowed sharing cookie data due to debugging issues and removed the need for a persistent ID to avoid misuse.
- **New API: curl_share_init_persistent** [04:51] — The accepted API for PHP 8.5 is `curl_share_init_persistent(array $shareOptions)`, which returns a persistent share handle. This handle can be passed to `curl_setopt` with `CURLOPT_SHARE` to enable sharing across requests.
- **Code example from RFC** [05:18] — The RFC provides a simple example: call `curl_share_init_persistent([CURL_LOCK_DATA_CONNECT, CURL_LOCK_DATA_DNS])`, then set the share handle on any cURL easy handle. This reuses connection and DNS data across requests in the same FPM/Apache process.
- **Demonstration with real code** [06:53] — The presenter runs a script that makes a request to app.tightways.io. The first request takes ~200ms (46ms DNS, 90ms connect), but subsequent requests to the same host drop to 84ms with no DNS or connect time. Changing hosts resets the overhead.
- **Future adoption and impact** [09:27] — The API will need to be integrated into libraries like Guzzle and Symfony HTTP client. Given the potential performance gains, the presenter is hopeful for quick adoption.

### Conclusion

The new PHP 8.5 `curl_share_init_persistent` API enables significant performance improvements for applications making repeated HTTP requests to the same hosts, potentially saving 5% or more of request time. This is a valuable addition for cloud and microservice architectures.

## Transcript

HTTP requests to the same hosts over and over again are currently wasting a measurable amount of time. When you perform HTTP calls in your PHP scripts, then the DNS resolving, opening the connection and TLS SSL handshake steps
are made over and over again in every request. In this video, I want to talk request. In this video, I want to talk about a new PHP 8.5 API to explicitly share connect DNS and SSL session information across PHP requests. And
this enables you to save a few milliseconds every request if you talk milliseconds every request if you talk to the same hosts. Example use cases are cloud and microser based architectures or with HTTP based databases such as
or with HTTP based databases such as elastic search. Mo, I am Benjamin and my work is focused on PHP performance topics for the last 10 years, helping thousands of developers along the way. Curl itself already supports configuring
what information should be reused within multiple requests using the same and different handles. On the C level, this is done using the curl share init function. And then you can call share opt set opt
And then you can call share opt set opt to lock the data for cookie DNS and uh to lock the data for cookie DNS and uh SSL session and connections. SSL session and connections. So there is the curl share init function
in PHP as well. It uh performs the same work. It's available for a very long time. However, uh the scope of this function is only to reuse this information across handles that are used
in the same um PHP request. So if you have two call handles here, curl handle one and curl handle two, then they can share in this case the uh cookie data
across the requests. Peace shared nothing architecture gets rid of this um nothing architecture gets rid of this um information after every request. And looking at curl get timers information we can roughly estimate this
to be a few milliseconds that we can save. I picked an endpoint in our tight save. I picked an endpoint in our tight application that can demonstrate this um not perfectly but I think it shows uh what the benefits we can see. So this
what the benefits we can see. So this endpoint here uh it's fairly fast most of the time and you can see that all of the time spent is HTTP requests. So if the time spent is HTTP requests. So if we look at a trace of this we can see
for 20 milliseconds about 18 milliseconds is or 19 milliseconds is milliseconds is or 19 milliseconds is HTTP and curl timer information shows HTTP and curl timer information shows that we have uh 1 millisecond roughly
that we have uh 1 millisecond roughly for connection and DNS lookup in every request so that we can save it's about 5% of the request time and if we have requests that use SSL this time becomes much larger as we can see later uh and
that can be shared and reused. So for PHP 8.4 Eric Norris proposed a persistent curl um share handle improvement RFC and this went through
improvement RFC and this went through two iterations and makes this possible. So Mati was quite excited about this at the time um because as a author of breath he certainly sees this as a problem. So establishing TCP and HTTP
connections every time can take like 100 to 200 milliseconds because of the HTTPS overhead and um this is something that we can save and uh it makes PHP in
general much faster. So let's go back to the RFC and uh see about the API and how it works. So the initial RFC, the first proposal initial RFC, the first proposal introduced a way to modify the curl
share in it function we saw before. The idea was that you can pass the options to share and provide a name for the persistent idea. And there were a few problems with that. The second iteration disallows sharing cookie data because um
this can cause problems that are very hard to debug. And then additionally um the problem is that users need to choose a persistent ID and if they do this um yeah badly then it might uh create a lot of
different ids um that have the same settings and also um if it's not immutable then there are problems down the line where you can change something making the API a little bit clumsy and pro problematic.
So the current uh accepted API that will be in PHP 85 is curl share init persistent. You pass an array of share options and then this uh returns a curl
share persistent handle function and um you can u provide this to the curl set uh fun set opt function with the share option. So let's see how this looks in
real code because this is a bit generic. Now the RFC for this change includes a simple code example that uh demonstrate simple code example that uh demonstrate the use of this. So you p call the curl
share init persistent function pass um curl lock data constant. For example, if you want to share connect and DNS data here, it uh returns a share handle and
then um you can set the share handle with this option to any um uh curl easy with this option to any um uh curl easy handle. And then um this this is now
handle. And then um this this is now reusing the connect and DNS data across handles not only within the same request but also across multiple calls of this but also across multiple calls of this uh script um in the same FPM or Apache
process. Let's look again at the RFC for some specific implementation details. So the we saw before cur lock data cookie is not allowed anymore because of
security reasons and uh making it hard to debug if that was available and also users no longer have to choose a persistent ID. So it's very easy to use this functionality and since um this new function returns a
and since um this new function returns a new handle it's also not possible to use new handle it's also not possible to use the old clunky curl share based APIs which are um not stateless so not immutable and this would cause problems.
Let's see for oursel how we can use this new PHP 8.5 API in a small code example. I've taken the code that we saw from the pull request before and modified it
slightly. So what did I do here? So I still have a function get curl handle. It um allows you to provide um a host name and a curl shirt persistent handle.
name and a curl shirt persistent handle. It then creates um a new um curl handle and returns that. and we use it to initialize um in a persistent connection for the connect session and DNS uh data and we
connect session and DNS uh data and we provide it a host through a URL either or um defaulting to app.tightways tight io we execute the handle then
uh we call get info and print out all the timers. the timers. So let's run this for um tideway.com. So we can see here that the total time is around 200
milliseconds uh of which 46 milliseconds are uh of which 46 milliseconds are um the name lookup and then until the connection is done and the transfer is starting um about 90 milliseconds are
long because it's within the docker network stack. So I used um docker um network stack. So I used um docker um PHP 8.5 beta 4 for this and um uh run
this through through the docker container. So if I run this again now uh container. So if I run this again now uh for the same host it lookup time anymore, no connect time anymore and the pre-transfer start time
like was reduced massively. So instead of around 200 milliseconds, the request now takes 84 milliseconds. Much faster. If I change the host to B appways.io,
so it's a different host now. Again, we can see 165 milliseconds. We have time spent in name lookup and connection time. And then if we rerun connection time. And then if we rerun the query, um, again, it's shared. Uh,
the data is not looked up anymore. And we see a massive improvement in the in we see a massive improvement in the in the time uh of this HTTP request.
improvement for scripts doing HTTP requests to the same hosts and uh a lot of applications are doing that and uh I'm really hopeful to see improvements to them in uh when they start using PHP 8.5. So obviously this will need uh some
time to get included into Gazle and Symfony HTTP client and other wrappers around curl so that we can see the benefits. But given that they look to become quite big, I'm hopeful it will not take a lot of time. If you're
interested in additional PHP performance topics, I have a video here on the channel on asynchronous HTTP connections with uh PHP and uh also a lot of uh with uh PHP and uh also a lot of uh additional content on various topics.
If you like to stay informed about PHP performance topics, please subscribe to the YouTube channel or our newsletter. The link is in the description. Bye.