Ok great, thought playing with gzipXXX size was enough :(
Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2012/11/29 AndyG <[email protected]>: > Hi Romain, > > I use RMIIO extensively for large binary transfer that I modified with an > almost identical fix to your flushable gzip implementation. I have tested > this to death with and without buffering/gzip in the past. > > I have found that gzip works substantially better with buffered streams over > a 'real' network, testing locally is unlikely to reveal massive gains on > small data - The gzip streams have a 4k buffer, buffered streams an 8k. > > The difference in IO code between OpenEJB and RMIIO for this sake is > trivial, so I have made an assumption (educated guess if you like) that this > can only be of benefit. > > One RMIIO cycling 50mb random binary write test I have is along the lines > of: > > client - buffer - gzip - network - buffer - gunzip - server - blob = 5sec > av. > > client - buffer - network - buffer - server - blob = 7sec av. > > And just tested without buffering... > client - gzip - network - gunzip - server - blob = 12sec av. > > So over a day quite a lot! > > Andy. > > > > -- > View this message in context: > http://openejb.979440.n4.nabble.com/Fwd-svn-commit-r1415122-in-openejb-trunk-openejb-server-openejb-ejbd-src-main-java-org-apache-openeja-tp4658985p4658989.html > Sent from the OpenEJB Dev mailing list archive at Nabble.com.
