tornado
tornado copied to clipboard
tornadoweb
Provide control over gzip compression level in tornado.web.Application
By default, GzipFile in the Python standard library uses a compression level of 9 (the highest available): https://docs.python.org/2/library/gzip.html#gzip.GzipFile
Most other applications (like the gzip command line tool) default to level 6 or lower. The difference in throughput can be something like a factor of 3-5x on a single core, leading many people to incorrectly conclude that using gzip compression with Tornado is "too slow" compared to other web servers (like node.js, for example, which led me to discover the cause of this problem).
It would be nice if the gzip option to tornado.web.Application could also be a number (1-9), indicating the compresslevel to pass to GzipFile. If True is passed, I would also advocate that a default value of 6 is used, rather than the standard library default. The compression factor will be very close to that of level 9, but throughput will be much larger.
If this sounds reasonable, I can make a PR.
Sounds good. In 4.0 the gzip parameter to Application was renamed to compress_response. This opens the door to (hypothetically) supporting other kinds of compression in the future, so maybe the value should be a dictionary of options like {'gzip': 9}? (in which case truthy non-dict values would be equivalent to compress_response={'gzip': 6}).
Does Tornado support that now? For example , i only want to gzip the static files.
No, this is not yet supported yet. The setting being proposed in this issue would still be an application-level setting that would apply to all handlers. I think you can set the header Content-Encoding: identity to turn off compression for a response, but I'm not sure if that will work with all clients.
Why do you want to treat static files differently from other responses for compression?
In case of a chatroom , where messages are very small, or event messages which are around 200-300 bytes , i think its not worth gzipping , its gonna be waste of resources. For that case , it will be worth not gzipping them?
OK, so it's not about static versus non-static, it's about the size of the response. This is something that we really should check (right now we will try to compress anything, no matter how small, which may even make the response larger once we add the gzip header), but I don't think it needs to be configurable. Just a fixed value for the smallest thing that's worth trying to compress (1KB?)
1KB by default make sense. Another way will be statically gziping and serving Via :
Content-Encoding gzip
Content-Type "text/css; charset=utf-8"
Content-Encoding gzip
Content-Type "text/javascript; charset=utf-8"
Haven't tried those with tornado tho.
Hi, I have set compress_response = True and used below: def get_compression_options(self): return {'compression_level':5,'mem_level':5}
still unable to compress the response. Could you pls guide me.
get_compression_options is a part of WebSocketHandler, not the base RequestHandler. We still don't support customization of compression in RequestHandler (that's why this issue is still open).
Simply setting compress_response=True in your Application should be enough to get the default compression behavior, though. Make sure you're using compression-aware clients and compressible media types.
This issue is about customizing compression behavior in RequestHandler; it's not the right place to talk about compression in websockets. Please open a new issue for this.