Question
Fauna Driver HTTP Connection Pool Sizing Limits
Lax Orbit
0 reputation · 24 Sept 2021, 03:56 UTC
91.5K views
Loading…
0 reputation · 24 Sept 2021, 03:56 UTC
Fauna drivers wrap an HTTP client to communicate with the database endpoint. To optimize performance and avoid socket exhaustion, the documented best practice is to instantiate a single, long-lived client and reuse it across the application lifecycle rather than creating a new client per request.
In high-concurrency environments or serverless runtimes, intermittent connection pool exhaustion can occur when the underlying HTTP client reaches its maximum socket limit. This is often exacerbated by aggressive retry logic or long-running queries that hold sockets open until a timeout is reached.
While reusing the client mitigates many issues, there is no standardized formula provided in the documentation to determine the ideal pool size relative to query concurrency and host runtime limits.
To balance query throughput against host file-descriptor limits, the maximum connection pool size should be set as a fraction of the available system file descriptors, ensuring that the driver does not compete with other critical system processes or application dependencies.
There is no universal formula, but the pool size is constrained by the lowest of three ceilings: the host's ulimit (file descriptors), the driver's internal HTTP client limit, and the database's concurrent request quota. To calculate a safe limit, use the following logic:
faunadbulimit -n on Linux).maxSockets or equivalent to the remaining budget, provided it does not exceed the expected peak concurrency of your application.If you set the pool size higher than the OS limit, the application will throw "Too many open files" errors. If you set it lower than your peak concurrency, requests will queue, increasing latency.
To ensure timely connection release and avoid "half-open" connections, the driver's internal idle timeout must be shorter than the platform's (load balancer or gateway) socket idle timeout.
If the platform closes a connection before the driver does, the driver may attempt to reuse a dead socket, resulting in 502 or 504 errors. Aligning them as follows is recommended:
To verify your configuration is performing as expected, use the following scoped commands during a load test:
# Monitor sockets in TIME_WAIT state to detect exhaustion
ss -tan state time-wait | wc -l
# Check current open file descriptors for the process
ls /proc/[PID]/fd | wc -l
Are you deploying to a serverless runtime (e.g., AWS Lambda, Vercel) or a persistent server? In serverless environments, singleton clients may be frozen between executions, which fundamentally changes how connection spikes are handled and may render standard pooling calculations ineffective.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.