views:

298

answers:

4

We are investigating the use of HTTP Compression on an application being served up by JBoss. After making the setting change in the Tomcat SAR, we are seeing a compression of about 80% - this is obviously great, however I want to be cautious... before implementing this system wide, has anyone out there encountered issues using HTTP Compression?

A couple points to note for my situation.

  • We have full control over browser - so the whole company uses IE6/7
  • The app is internal only
  • During load testing, our app server was under relatively small load - the DB was our bottleneck
  • We have control over client machines and they all get a spec check (decent processor/2GB RAM)

Any experiences with this would be much appreciated!

+1  A: 

Compression is not considered exotic or bleeding edge and (fwiw) I haven't heard of or run into any issues with it.

jdigital
+1  A: 

Compression on the fly can increase CPU load on the server. If at all possible pre-compressing static resources and caching compressed dynamic responses can combat that.

Bryan Kyle
+1  A: 

As long as you respect the client's Accept-Encoding header properly (i.e. don't serve compressed files to clients that can't decompress them), you shouldn't have a problem.

Oh, and remember that deflate is faster than gzip.

Ant P.
+1  A: 

It just a really good idea all the way around. It will add slight CPU load to your server, but that's usually not your bottleneck. It will make your pages load faster, and you'll use less bandwidth.

Daniel Von Fange