Vaadin Sampler gzip

Am I right that Sampler doesn’t use gzip encoding for uidl requests?
If so, then what’s the reason?
Looking at firebug net graphs it appears that most of requests are couple of kbytes length and half of time is spent receiving data (100-400ms on my 4mbps connection).
This looks like an obvious way to improve performance, am i missing something?



You mean the one at, right? That does seem to be the case - I’m going to talk to the administrator about that right now.

Note that this is a server configuration - for instance in tomcat you should configure your connector to have
and also the mime types that should be compressed with e.g
. I’m guessing application/json is missing from the conf…

Thanks for noticing!

Best Regards,

I talked to the administrator, and this does indeed seem to be the case - it’ll probably be enabled later today.

// Marc

Ok, there is even more to this:

Gzip should usually be enabled for responses that exceed 150 bytes (Google
a limit between 150-1000 bytes), but for UIDL responses we do not know the content-length, and thus either all responses will be compressed, or no responses will be compresses.

In effect it’s a tradeoff, and you’ll have to decide whether most of your UIDL responses are over the recommended length limit so that it’s worth compressing all of them, even if they fall below the limit. Then add or remove application/json from the compressed mime-types depending on your decision.

At least that’s how I understand the situation at the moment…

// Marc

Even more about the content-length:

ATM 69 bytes seems to be the minimum content-length from a simple operation that does nothing. Obviously this is a very rare thing, and you’ll find that in practice the content length almost always exceeds 150 bytes. As the OP noted, this can be verified by trying Sampler and viewing the XHR responses.

// Marc

Thanks, Mark.

I see that it’s now enabled and feels much snappier.
This cleared most of my concerns about vaadin performance.