We have a bespoke WordPress plugin, which adds a meta box to the edit post page. The plugin accesses data from a semi-private HTTP REST API.
The connection is authenticated (DIGEST) and accessed regularly – every person writing a post will interact with it several times (usually in tight bursts) and there are > 100 such people. So, we would like to ensure the HTTP calls are working efficiently. We see two problems:
- No evidence of Keep-Alive being used to stop the TCP socket opening
and closing constantly.
- Every request is done twice for the DIGEST authentication. Since it is the plugin that is authenticated (not the user) this is > 99% waste. Apache have called their solution for this pre-emptive authentication.
We can see latency in the meta box as users interact with it, so this is a real issue.
I hear some of these problems can be solved by re-using the cURL handle, but cannot find any best practice advice around implementing that in a WordPress plugin specifically. One issue we have with that is that WordPRess effectively re-initialises the plugin on a per request basis, as far as we can tell.
It is not possible, at least not within reason, to solve either of these issues due to fundamental limitations of PHP in a web envionment (mod_php).
Class variables do not persist between web requests, so the Keep-Alive part of the problem cannot be fixed because all the resources (i.e. curl handle, tcp socket) will be destroyed at the end of the request. Re-using the cUrl handle seem to be mostly relevant to batch scripts or the rare web-script that needs to access multiple URLs in one go. The kind of performance optimizations considered standard for Java developers are therefore unavailable to PHP developers.
One could try to implement digest authentication by sticking the values for the Authorization header into session, but that is not cheap to implement (high dev time) and not something that many enterprises want to dedicate time to. This might be a nice 3rd year university project for example.
Hopefully, at some point, someone will release an add-on product for PHP in Apache that somehow channels HTTP requests through to a TCP connection pool external to the process. That would probably make money, given that it will knock a lot of latency off upstream HTTP requests from PHP.
