Pre-Compress GWT compiler output for web server

[martinhansen]

Hello,

I am evaluating some approaches to reduce the amount of data being
transmitted to the client browser. I am using the Apache Tomcat web
server. I successfully managed to enable GZIP output for the Tomcat
server by editing the server config file. It works fine. However, this
way the data is compressed on-the-fly by the web server for every
request which considerably increases server CPU load. Is this
assumption correct?

Is there a way to pre-compress the contents of my GWT app and have
this pre-compressed content delivered by the web server?

[martinhansen]

I've found an interesting tool for Java EE applications and Tomcat
server:

:-) http://www.xucia.com/#Resource%20Accelerate :-)

ResourceAccelerate... it can cache the gzip output of tomcat and
thereby reduces the need to re-compress files for every request.
Great!

What do you think of it?

On 22 Jul., 13:06, martinhansen <martin.hanse...@googlemail.com>
wrote:

[Bob Rozelle]

A solution for the *.cache.html files is to gzip them
to .cache.html.gz files.

If you are using Apache as your web server you can then modify the
mime.conf file (found at /etc/apache2/mods-enabled/mime.conf) by
uncommenting:

AddEncoding x-gzip .gz .tgz

and commenting:

#AddType application/x-gzip .gz .tgz


This means that my apache server will send the .cache.html.gz files in
replacement for the .cache.html files and also send the response
header: content-encoding=gzip

This can also be done in a .htaccess file (RemoveType and AddEncoding)
placed in the cache folder.


On Jul 22, 7:06 am, martinhansen <martin.hanse...@googlemail.com>
wrote:

[hazy1]

It is dead simple to create a simple in-memory cache in your web
application for gzipped data. Gzip the web page in memory the first
time it is created and then use this for subsequent requests to that
resource.

On Jul 22, 7:06 am, martinhansen <martin.hanse...@googlemail.com>
wrote:

[JavaTech]

[JavaTech]

Hi all
I am using the Tomcat 6.0

As i believe we need to setting the web.xml in the following path C:
\Program Files\Apache Software Foundation\Tomcat 6.0\conf as below

am i right
<!-- <extension>gz</extension>
<mime-type>application/x-gzip</mime-type>
-->
- <extension>Encoding</extension>
<mime-type>x-gzip</mime-type>
it is not working

kindly let us how to resolve this issue.

Regards,
Thilak

On Jul 23, 9:14 am, hazy1 <matt.egyh...@gmail.com> wrote:

[Dhamu]

Hi,

Any update on this?
How can i tell to tomcat about gz files of GWT?

Thanks

[Joseph Lust]

The general solution is to setup your Tomcat behind an Apache server. mod_headers works well on just Apache, so you can use a filter there with mod_headers to add the gzip headers. This way the browser knows that this js file is gz encoded.

A tip, I noticed if I just name files like script.js.gz, some firewalls tried to convert them to gzip MIME from JS (because they saw the .gz), breaking the app. So, I just made up my own ending and called it .jsz. Now I can easily just *.jsz to applied mod_headers too.

You can also create your own filter and do this all in Tomcat (like this example), but remember this adds overhead and complexity, so why not just let Apache do it for you?

Sincerely,

Joseph

[Thomas Broyer]

On Monday, October 29, 2012 6:46:45 PM UTC+1, Joseph Lust wrote:

The general solution is to setup your Tomcat behind an Apache server. mod_headers works well on just Apache, so you can use a filter there with mod_headers to add the gzip headers. This way the browser knows that this js file is gz encoded.

Much easier with MultiViews, and your *.js.gz and *.js files are both served from the same *.js URL.

But what's the problem with enabling compression on Tomcat and/or using a GzipFilter (e.g. on Jetty)?

[Joseph Lust]

@Thomas, I prefer to precompress the files where I can since there is no reason to waste the overhead recompressing them each time they're served, and since GWT supports precompression at build time.

Of course you can set it up anyway you like with a pure Tomcat/Jetty setup as you point out.

Sincerely,

Joseph