On 06/02/12 17:21, Robert Vesse wrote:
On a local network it does not seem to be beneficial, it adds a few
seconds of overhead.
I was trying gzip (in Java) today for Fuseki backups - I found similarly
that writing to disk was faster without gzip.
The Java gzip was about "gzip -6" in time and space reduction achived
with large enough gzip buffer - I used 8K where the default is 0.5K.
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.
I think that's correct generally, not a Jetty-ism. If the client does
not ask for it, it should not happen (the client may not have the
ability or desire to uncompress e.g scripting languages, curl etc).
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.
Agreed. Off by default.
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.
ARQ isn't being released - just Fuseki so this is less time critical.
Andy
