Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Switching to aiohttp? #4560

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mamad0901-sys opened this issue Nov 7, 2024 · 5 comments
Open

Switching to aiohttp? #4560

mamad0901-sys opened this issue Nov 7, 2024 · 5 comments
Labels
πŸ“‹ triage work status: triage

Comments

@mamad0901-sys
Copy link

mamad0901-sys commented Nov 7, 2024

What kind of feature are you missing? Where do you notice a shortcoming of PTB?

Performance Improvement

Hi
Thanks for this great project.
Are there any plans to switch to aiohttp in future?

Describe the solution you'd like

It seems like aiohttp performs faster in async projects (specially the ones with high volumes of traffic).

There are some benchmarks that prove this:
For example this one from 2020 suggests that aiohttp performs faster in both single-request and multiple-requests sessions:

encode/httpx#838

The code used in the test above seemed very simple and logical, so I reran it with the latest versions of both modules on my own machine and got the same results in favor of aiohttp:

aiohttp

$ wrk http://localhost:8000/aiohttp/session

Running 10s test @ http://localhost:8000/aiohttp/session
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    20.06ms    2.86ms  45.07ms   94.14%
    Req/Sec   250.26     23.66   303.00     77.00%
  4989 requests in 10.01s, 711.32KB read
Requests/sec:    498.41
Transfer/sec:     71.06KB

httpx

$ wrk http://localhost:8000/httpx/session

Running 10s test @ http://localhost:8000/httpx/session
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    54.59ms   28.80ms 163.58ms   79.85%
    Req/Sec    92.11     19.31   140.00     68.50%
  1839 requests in 10.01s, 262.20KB read
Requests/sec:    183.67
Transfer/sec:     26.19KB

Therefore httpx is about two to three times slower when re-using a session for requests. My results too showed even more slower performance of httpx in single-request sessions (which is not very important in this project)

Other than speed differences, it might even suggest that aiohttp uses less resources like CPU too (maybe).

Thanks

Describe alternatives you've considered

Using aiohttp

Additional context

No response

@mamad0901-sys mamad0901-sys added the πŸ“‹ triage work status: triage label Nov 7, 2024
@mamad0901-sys mamad0901-sys changed the title Switching to aiohttp? [IMPROVEMENT] Switching to aiohttp? Nov 7, 2024
@Bibo-Joshi Bibo-Joshi changed the title [IMPROVEMENT] Switching to aiohttp? Switching to aiohttp? Nov 8, 2024
@Ousret
Copy link

Ousret commented Nov 8, 2024

There's an another option that can be considered.
You could look at Niquests. It is faster than httpx, but sure be slower than aiohttp in your current code architecture. The pro would be to not drop http2 support and have a better and reliable multiplexed connection. it is also http3 ready, but as far as I know telegram API isn't ready yet. I think that OS trust store native access alongs with DNS over HTTPS mixed with Happy Eyeballs could benefits your users.

@Bibo-Joshi
Copy link
Member

Hi. Sorry for the late reply.
Your suggestions are very insteresting!

I would like to point out that PTB is already designed such that it's easy to use a custom networking backend, see this wiki entry as well as the docs of BaseRequest. Using aiohttp or niquests as networking backend is hence already possible.

After discussion in the dev chat, we're not (yet?) prepared to add additional network backends directly in PTB or completely replacing HTTPXRequest. What we would like to propose instead is to make aiohttp and niquest implementations of BaseRequest available through ptbcontrib as a start. This will allow a larger user base to test these rather easily, while not affecting the main lib. @Poolitzer has expressed that he'd be willing to support with this.

If these alternative implementations gain some traction and can maybe even be shown to also perform better than httpx in TG specific comparisions, we're ofc willing to reconsider and add additional implementations to the main lib. I'm mentioning "TG specific comparisions" also b/c in the past we were maintaining a vendored version of urllib3 b/c there were issues with it that were only happening when using it with the bot API and couldn't be reproduced in other settings.

Let me know what you think.

@mamad0901-sys
Copy link
Author

mamad0901-sys commented Nov 23, 2024

That would be great.
I tried to use my own implementation of BaseRequest using aiohttp as suggested in BaseRequest but wasn't be able to handle different errors.

my implementation

So I would really appreciate it if any of the devs could implement a better one in ptbcontrib

Thanks

EDIT: I updated the code above, and now the errors are handled as expected :)

@psykokwak-com
Copy link

Thanks @mamad0901-sys,
I used your aiohttp implementation with some modifications.
It works much better. I am able to handle thousands of bots at the same time without any problems.
Whereas before I had connection problems and slowdowns.

@Bibo-Joshi
Copy link
Member

Hey. I admit that I had forgotten this thread a bit :/ @mamad0901-sys you're welcome to send a PR against ptbcontrib. I can do some reviews, but doing the implementation on PTB-team side is currently out of scope. We'll still leave this issue open so that people can express their support if they want to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
πŸ“‹ triage work status: triage
Projects
None yet
Development

No branches or pull requests

4 participants