What's the difference between async and blocking client when using HTTP/2

[kice]

My goal is to use fewer connections but getting more requests per second (or maximizing requests speed per connections).

I tried using normal client to send streaming requests, and then getting the respond in other threads, but looks like the OS dose not like this.

Just don't want to use async api because is it quite hard to debug in python.

[Bluenix2]

I am a bit confused about what the OS has to do with this; are you noticing it creating more sockets than you'd expect?

To verify whether that is true, it'd be good if you included a reproducible example - I suspect that there may be a misunderstanding of HTTP/2.

If your goal is to use fewer connections and by doing so increase RPS then HTTP/2 is the right choice -- but so is async. The async API is all about maximizing performance of one thread: when one task is waiting for a response you can have another one sending another request or even simultaneously waiting for another response on the socket (at least in theory of how HTTP/2 works; I don't know enough about HTTPX's internals to say whether that is allowed).

I disagree about the async API being hard to debug in Python, in fact the opposite is true because of cooperative scheduling. There's much less race conditions possible in your application when using async. Threading is notoriously difficult to get right:

multithreading.mp4

[kice]

For blocking API, I tried the following

• one client per thread, which is not what I want
• OR maybe request as streaming, and then use other threads to receive the response (ONLY ONE thread is sending requests, and other threads are receiving using the httpx.Response object)
• OR share httpx.Client instance across threads (sending and receiving done in the same thread)

But only the first case cause no issue but the number of connections is the same as the thread.
The rest use case will cause exceptions. If it works just fine, try to download something large.

Base on current httpx implementation, sharing httpx.Response or httpx.Client with only one connection limits=httpx.Limits(max_connections=1, max_keepalive_connections=1) is not 100% thread safe.

For the first part you explaining how async API works, I think one of the biggest selling points of HTTP/2 is allowing clients to send a lot of requests at the same time and then wait for them whenever you want using one connection. Looks like httpx.Client does not have this "pipelining-like" feature, which is the thing I would like know if I am correct or not.

Due to some reasons, I need to reset the http client from time to time, and if you could provide me some example would be helpful.

[Bluenix2]

If it doesn't work, that would be a bug. You can see here that the HTTP/2 implementation does locking at several levels to be secure against race conditions involved with context switching. These locks imply that HTTP/2 connections are being shared (like they're supposed to, to be able to take advantage of HTTP/2).

As for the last paragraph, how you reset the client is up to you depending on purpose of resetting it. Easiest way would be just closing down the current client after having opened a new one. I really don't see the point though.