TestClient slows with multiple calls to websocket_connect #2570
Unanswered
NPrescott
asked this question in
Potential Issue
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I noticed an anomalous slow down in a test in which multiple
websocket_connect
calls are made usingTestClient
. In particular this was most egregious on a single machine but I've validated a more modest slow down across multiple machines.I've pared back the application and test to this:
In the case where I noticed the problem there is a dramatic increase in execution time between a test with one call to
client.websocket_connect
and two. For the above:If I remove the second call to
websocket_connect
:Specifics of the environment:
I've been unable to identify what makes the machine notable compared to others that don't demonstrate the same severity. In order to observe an increase in execution time on other machines I've had to include 20 calls to
websocket_connect
but an impact is observable.I spent some time trying to investigate the source of the slowness and turned up mostly time spent on futex, I think linked to the queues backing send and receive in the TestClient. I was able to at least partly confirm issues with the scheduling by pinning the test to a single CPU (where the machine has 8 total), no particular CPU matters for this case:
Trying to identify potential sources of CPU contention or difficulty I turned up starlette.testclient.WebSocketTestSession._asgi_receive which is testing the receive queue and conditionally invoking
anyio.sleep(0)
. In my case I believe this will resolve to a special coded case of asyncio that immediately yields to the TestClient threaded event loop.I don't totally grasp the interaction causing a problem here but suspecting the loop was spinning on the lock backing the Queue I tried modifying
_asgi_receive
like this:And observed an improvement in execution speed to a level I expect:
As mentioned, this effect issue seems less pronounced on other machines but observable with tens of calls to
websocket_connect
. In such a case on a less problematic machine the above patch produces a more modest speed up in the range of 10x.A search of the discussion history turned up Testing interaction of WebSockets with TestClient imposes thread safety? which did not seem directly applicable and has been noted to no longer be a problem with recent releases.
I am filing this under "Potential Issue" because I am unable to identify why one machine in particular is so susceptible to the problem and I have two different solutions available. I suspect this can mostly serve as documentation in case anyone else tries searching for the problem like I did.
Beta Was this translation helpful? Give feedback.
All reactions