Client / AsyncClient instantiated extremely slow

[TrueRou]

Client / AsyncClient instantiated extremely slow (over 200ms).

The examples are making only one request by Client, this may cause misleading.

>>> async with httpx.AsyncClient() as client:
...     r = await client.get('https://www.example.com/')
...
>>> r
<Response [200 OK]>

Though there were docs about clients, developers did not know that not only they can't get the most benefit from connection pooling, BUT ALSO face over 200ms cost to create client itself. TUN Proxy will aggravate the condition by 2 ~ 3 times.

Warning
In order to get the most benefit from connection pooling, make sure you're not instantiating multiple client instances - for example
by using async with inside a "hot loop". This can be achieved either by having a single scoped client that's passed throughout
wherever it's needed, or by having a single global client instance.

Code:

import httpx
import time
import asyncio


async def test_async_client_creation_time():
    start_time = time.time()
    async with httpx.AsyncClient() as client:
        end_time = time.time()
        print(f"AsyncClient creation took {end_time - start_time:.6f} seconds")


def test_client_creation_time():
    start_time = time.time()
    with httpx.Client() as client:
        end_time = time.time()
        print(f"Client creation took {end_time - start_time:.6f} seconds")


# Run the async function
asyncio.run(test_async_client_creation_time())
# Run the sync function
test_client_creation_time()

Results:

AsyncClient creation took 0.389101 seconds
Client creation took 0.202185 seconds

[ketpatil77]

There is setup work before the first request: constructing the default transport creates an SSL context and loads trust information. Environment-derived proxy transports can add setup too. Your timings alone do not identify which part dominates on your machine, but they do measure more than entering an empty async context manager.

Keeping one client for the logical workload amortizes both that construction cost and connection setup. If you genuinely need several clients with separate cookies/authentication, you can additionally reuse a configured SSL context:

import ssl
import certifi
import httpx

# Once at application startup; configure the CA policy your deployment needs.
tls = ssl.create_default_context(cafile=certifi.where())


async def fetch_statuses(urls):
    async with httpx.AsyncClient(verify=tls) as client:
        statuses = []
        for url in urls:
            response = await client.get(url)
            statuses.append(response.status_code)
        return statuses

Sharing tls between otherwise separate clients avoids reloading that same CA bundle per client; it does not share their connection pools. Configure the context before use and retain the certificate verification you need. In particular, an explicit context makes its CA selection your responsibility if you previously relied on SSL_CERT_FILE, SSL_CERT_DIR or private CAs.

For profiling, compare client construction separately from the first request, and compare the default verify=True path with an already-created context. trust_env=False is also a useful diagnostic only when ignoring environment proxy/CA settings is appropriate; it changes behavior and is not a general fix for a required proxy.

SSL context configuration and async client lifetime guidance. AI-assisted; checked SSL-context reuse in the construction path and the single-client/multiple-request example locally on HTTPX 0.28.1. No universal constructor timing is claimed.