Repository navigation
Add Http::pool() for concurrent HTTP requests - #17
Merged
Merged
Conversation
Http::pool() sends many requests at the same time through WordPress's
bundled WpOrg\Requests transport. A consumer that downloads ~22 images
one after another (~45 s) can now fetch them in about the time of the
slowest request.
$responses = Http::pool(function (Pool $pool) use ($urls) {
foreach ($urls as $key => $url) {
$pool->as($key)->timeout(15)->get($url);
}
}, ['concurrency' => 10]);
- New Pool and PooledRequest. A pooled request has the full fluent
Request API. Its verb methods record the request instead of sending
it. Responses come back in the order the requests were added, keyed
by as($key) or by the next integer index.
- Request::send_request() is split into build_request() and dispatch(),
so pooled and single requests are built by the same code. Single
requests still go through wp_remote_request() unchanged.
- The pool does for each request what WP_Http::request() (WP 6.9.4)
does: default-argument filters, http_request_args, the
pre_http_request short-circuit, wp_http_validate_url/block_request
checks, Requests options (SSL/CA bundle, https_ssl_verify, proxy,
redirect hooks, cookies, streaming, max_bytes), the response array
shape, http_api_debug and http_response.
- Requests that need the network are sent in batches of `concurrency`
(default 10). Short-circuited and rejected requests do not take a
slot. A failed request becomes a Response that wraps a WP_Error and
never affects the others. A duplicate key or an invalid concurrency
throws before anything is sent.
- Fix: Response::failed() now returns true for a WP_Error. It used to
return false, because the status read as 0.
- Test stubs: add_filter/apply_filters now run callbacks, and there
are stand-ins for the WP HTTP classes and a RecordingPool seam.
Adds 36 tests; the full suite passes (935).
- docs/http-client.md, a new CHANGELOG.md, and version 3.3.0.
Verified on the Docker playground (WP 7.0): five requests that each
take 1 s took 5.04 s one after another and 1.01-2.02 s pooled. The
scoped output keeps WpOrg\Requests and WP_* global.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Http::pool() sends many requests at the same time through WordPress's bundled WpOrg\Requests transport. A consumer that downloads ~22 images one after another (~45 s) can now fetch them in about the time of the slowest request.
concurrency(default 10). Short-circuited and rejected requests do not take a slot. A failed request becomes a Response that wraps a WP_Error and never affects the others. A duplicate key or an invalid concurrency throws before anything is sent.Verified on the Docker playground (WP 7.0): five requests that each take 1 s took 5.04 s one after another and 1.01-2.02 s pooled. The scoped output keeps WpOrg\Requests and WP_* global.