I was planning to add the feature as filters in Coyote HTTP/1.1, but
never did, because I wasn't able to find efficient compression code.
I suppose something could be put together using the JDK compression
IS and OS in the meantime.
GZIPOutputstream is quit fast today.
I think I'll disagree whenever I'll try it.
C'est le jeu ;)
Ideally, I'd like a ByteChunk compress(ByteChunk) with nice recycle
methods so that no object even gets allocated.
Right, but I'm currently playing with stuff which read/write
large files, and reading/writing with GZIPxxxxstream make the
program 4* faster !
I hope someone could works on it at the coyote level to make
it available for both HTTP 1.1 and JK2 upper layers.
You can't do it, unless the code is in the adapter, and that's bad
design (it's a protocol feature, so it should be in the protocol hanlder).
Couldn't the compression goes in filter, like Amy does sometimes ago ?
The compression code should go in a filter for HTTP/1.1. For the native
webserver connector, like JK2, I insist that this is to be done in the
native code.
Just take an example :
If a servlet has to respond a 100K content, and you're using
webserver+jk via net/ajp13, tomcat will send 100K by the
network which will be compressed 'à la volée' by mod_deflate.
You've got a 100K network use (tc->webserver) + about 30k
network use (webserver->browser).
If you've got the compression done in java side, you'll have
only 30+30 network use and you know that bandwidth today is
more important for IT and ADMINs that CPU/RAM.
May be a solution could be to bench and optimize the Amy works
on gzip compression filter ?
Of course compression may also be present in browser->server,
ie while uploading large file.
When you're using tomcat/jk in SOAP situation, having gzip
activated make operation appears really quickers since the
volume of datas in both side could be important.
Just my 0.01 EUR.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
