On a local network it does not seem to be beneficial, it adds a few seconds of overhead. Due to other more pressing work I haven't had chance to test for the overheads when used over a decidedly non-local network though I should get chance to do that later today at which point I'll submit the patch.
The Fuseki patch I have at the moment enables the filter by default but due to the way Jetty works the filter only gets applied if the client explicitly states that they accept GZip encoded content with the Accept-Encoding parameter. Browsers typically send this so it may be that it would be best to have this feature off by default because if people do prototyping and testing on their local machine with their browser they may see slower performance because of this. However most SPARQL clients in various APIs probably won't include this header by default - whether this wants to be enabled by default will probably depend on the performance figures. I'll aim to have the submitted patch make the behavior configurable and leave it up to you whether you want to have it enabled/disabled by default once you've seen the figures. Rob ps. I also have a related patch for ARQ which allows it to ask for GZip and Deflate encoded content though I'll likely package that as part of a more extensive patch for QueryEngineHttp I've been working on which also adds in support for configuring requested content type. On Feb 4, 2012, at 3:48 AM, Andy Seaborne wrote: > Rob, > > Go for it! It's a good feature to have as result sets can be very large, as > can models and this wil work nicely with streamed triples as results. > > I do need to do the release of Fuseki because I feel bad at pointing point to > snapshots all the time but a few days is fine. I'll be doing TDB and Fuseki > separately so TDB, vote cycle, release, then, if we are all agreed on a > Fuseki release. > > Question: > > When is gzip'ing beneficial? On a local network, it might not be - I've > assumed (without up-to-date facts) that the gzip costs are more time than > xfer of the uncompressed bytes. > > So would this be on by default in the client? Maybe it should, maybe it > shouldn't. > > Have you found any good links that describe the experience of using gzip'ed > streams elsewhere? > > Andy > > On 03/02/12 19:44, Robert Vesse wrote: >> Yes I basically just added GzipFilter to some of the servlets >> >> Rob >> >> On Feb 3, 2012, at 10:23 AM, Stephen Allen wrote: >> >>> Hi Rob, >>> >>> Just a quick question. Are you implementing this with a Servlet >>> Filter? That's what I've done successfully in the past to add GZip >>> support to Joseki with Jetty [1] (also created one to perform XSL >>> transformations on the server instead of the browser). >>> >>> -Stephen >>> >>> [1] >>> http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/servlets/GzipFilter.html >>> >>> >>> On Fri, Feb 3, 2012 at 9:38 AM, Robert Vesse<[email protected]> wrote: >>>> Hey >>>> >>>> I know the release process is moving along so I wanted to check whether >>>> there was a deadline for patches for inclusion in the Fuseki 0.2.1 release? >>>> >>>> I've been working on a patch the last couple of days which enables GZip >>>> support so clients can use Accept-Encoding: gzip and Fuseki will >>>> automatically gzip the responses if appropriate. I have some more testing >>>> to do on this and some related patches for ARQ which enable remote SPARQL >>>> execution to use GZip and Deflate encoded results but I hope to submit >>>> this patch in the next few days. >>>> >>>> Cheers, >>>> >>>> Rob >> >
