[00:02] 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
[00:17] 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
[00:33] 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
[00:47] 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
[01:00] 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
[01:16] 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
[01:31] 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
[01:46] 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
[01:58] 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
[02:12] 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
[02:25] 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
[02:39] 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
[02:52] 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
[03:09] 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
[03:22] 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
[03:38] 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
[03:51] 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
[04:05] 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
[04:21] 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
[04:37] 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.
[04:51] 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
[05:05] 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
[05:18] 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
[05:32] 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
[05:44] 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
[05:57] 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
[06:11] 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
[06:23] 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
[06:38] 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.
[06:53] 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
[07:05] 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.
[07:18] 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
[07:35] 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
[07:47] 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
[08:03] 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
[08:19] 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
[08:32] 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
[08:48] 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,
[09:01] 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,
[09:15] 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.
[09:27] 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
[09:45] 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
[10:01] 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.
[10:16] 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.