Guzzle Pool: Performance degradation under high concurrency

[francescobianco]

Labels: performance, investigation, guzzle
Context: Bulk API requests using GuzzleHttp\Pool

Description:
When sending 100+ requests in parallel through Guzzle's Pool, Openapi SDK instantiates a new Guzzle client per request, defeating connection reuse.

Expected:
Reuse HTTP client instance and enable keep_alive option.

Impact:
Response latency increases exponentially and API rate-limits are hit sooner.

[Seraphim200001]

Hi 👋

This issue should also be resolved (or significantly improved) by the changes introduced in the PR I recently opened for Ticket #6.

✅ What changed

The SDK now allows injecting a custom HTTP client instance into the Client instead of internally creating one for each request.

🎯 Why this helps

Previously, the SDK handled HTTP requests internally (via cURL), which made it impossible to:

reuse connections
benefit from persistent clients
integrate with tools like Guzzle’s Pool

Now you can pass a single, pre-configured HTTP client instance and reuse it across all requests.

📈 Result
The same HTTP client instance is reused
Connections can be kept alive
Compatible with Guzzle pooling and parallel requests
Avoids creating a new client per request

📈 Result
The same HTTP client instance is reused
Connections can be kept alive
Compatible with Guzzle pooling and parallel requests
Avoids creating a new client per request

[francescobianco]

Great work @Seraphim200001, thanks a lot for this! 🙌
We’re currently reviewing it and aiming to merge it soon. I’ll let you know if we need any changes 👍