-
Notifications
You must be signed in to change notification settings - Fork 3k
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
FastHttpLocust is very slow at returning the response text #1193
Comments
Oh, and also it doesnt cache the value, so every call to .text will need to decode the string again. I'm looking in to it... |
Oh, the actual problem is the character encoding detection in apparent_encoding() |
I can solve this by using cchardet instead of chardet. Encoding detection time drops from 12 seconds to 0.03s for me. @heyman ok to add this as a dependency? |
Or we could just read the Content-Type: charset header? |
Yeah, maybe that's best. And assume ISO-8859-1 if none is specified. I guess it could cause problems when the server is setting incorrect chaset headers, though it shouldn't be that big of a problem since users of a load testing tool usually have control over both client and server side. |
I'll have a go at it |
…g chardet, as was previously done automatically, but removed to fix #1193). Dont catch exceptions that can't happen any more or at least should very rarely happen, and we can leave it to the user to handle them.
Getting resp.text when using FastHttpLocust does a string decode (fasthttp.py:257) and it is crazy slow for large responses (~12s for a 1.5MB payload).
The text was updated successfully, but these errors were encountered: