You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My Trio app is making simple, periodic (persistent connection), non-SSL get requests for content of ~200K. I noticed high CPU use due to this request and confirmed with a sampling profiler.
I replaced use of asks with a bare-bones HTTP get implementation using Trio high-level networking and httptools for parsing. CPU use due to the HTTP requests decreased significantly (from about 11% to 3% of total app CPU), despite both implementations using Trio networking with a 10,000 byte receive size.
The profiler suggests that h11's next_event() adds significant overhead (4.3% of app total). The code of _catch_response proper is adding overhead as well (.9%). Generally the size of the call stack is alarming-- it goes on for pages.
The text was updated successfully, but these errors were encountered:
My Trio app is making simple, periodic (persistent connection), non-SSL get requests for content of ~200K. I noticed high CPU use due to this request and confirmed with a sampling profiler.
I replaced use of asks with a bare-bones HTTP get implementation using Trio high-level networking and httptools for parsing. CPU use due to the HTTP requests decreased significantly (from about 11% to 3% of total app CPU), despite both implementations using Trio networking with a 10,000 byte receive size.
The profiler suggests that h11's
next_event()
adds significant overhead (4.3% of app total). The code of_catch_response
proper is adding overhead as well (.9%). Generally the size of the call stack is alarming-- it goes on for pages.The text was updated successfully, but these errors were encountered: