Backend Development 8 min read

Impact of System Load on libcurl DNS Resolution and HTTP Timeout

This article investigates how high system load affects libcurl's DNS resolution time and overall HTTP request latency, explains the three timeout error types returned by libcurl, presents experiments comparing host‑based, system‑host, and async‑ares resolution methods, and offers optimization recommendations.

Beike Product & Technology
Beike Product & Technology
Beike Product & Technology
Impact of System Load on libcurl DNS Resolution and HTTP Timeout

In modern micro‑service architectures, services frequently call each other via HTTP, and RPC timeouts are a common alert, often categorized as "Resolving timed out", "Connection timed out" or "Operation timed out".

These messages originate from libcurl, which under the hood checks request state and elapsed time; when the timeout expires before completion, it reports the appropriate error based on the current phase (DNS resolution, connection, or other operation).

The author conducted experiments on a virtual machine, measuring DNS resolution time and total request latency with curl under varying system loads (idle, load ~20, load >90). Results showed that as load increases, both overall latency and DNS resolution time grow dramatically.

To explore mitigation strategies, three alternatives were tested alongside the default libcurl behavior:

Using the --host option to bypass DNS resolution.

Adding static entries to the system /etc/hosts file.

Enabling libcurl's async‑ares mode for asynchronous DNS resolution.

Experiments (50 requests per scenario) revealed that:

All methods incur higher latency under higher load.

System host entries have little effect on DNS time under load.

The --host option eliminates DNS time but increases connection time, yet still yields the best overall performance.

Async‑ares significantly reduces DNS latency in high‑load situations.

Technical analysis shows that async‑ares implements its own non‑blocking DNS resolver, avoiding the platform’s blocking APIs and allowing callbacks to manage socket states, whereas libcurl’s default async‑thread creates a helper thread whose synchronization overhead degrades performance under CPU pressure.

Consequently, the recommended solutions are to use the --host option when possible, enable the ares resolver in libcurl, or reduce overall system load to improve DNS resolution performance.

Overall, high system load can severely impact curl’s DNS resolution, and adopting async‑ares or bypassing DNS can mitigate the issue.

BackendDNScurltimeoutasync-aressystem load
Beike Product & Technology
Written by

Beike Product & Technology

As Beike's official product and technology account, we are committed to building a platform for sharing Beike's product and technology insights, targeting internet/O2O developers and product professionals. We share high-quality original articles, tech salon events, and recruitment information weekly. Welcome to follow us.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.