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!
Compression is not considered exotic or bleeding edge and (fwiw) I haven't heard of or run into any issues with it.
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.
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.
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.
Related
I recall a very fast kernel module for Linux called "TUX" for static files to answer IIS's superior-to-Linux static file web-serving performance and solve the "C10K problem." Now I keep seeing:
Nginx
Lighttpd
CDNs
... for "fast static file-serving." Serving static files quickly isn't difficult if your OS has the right features. Windows has since the invention of IO Completion ports, overlapped I/O, etc.
Did Tux die because of the security implications? Was it an experiment that Kqueue/Epoll combined with features like Sendfile made obsolete? What is the best solution to serve 100% static content -- say packshots of 50 or so images to simulate a "flipbook" movie.
I understand this ia "Server-related" question, but it's also theoretical. If it's purely static, is a CDN really going to be better anyway?
Mostly because Ingo Molnár stopped working on it. Why? I believe it was because kernel version 2.2 implemented the sendfile(2) call which matched (approximately) the massive performance benefits previously achieved by Tux. Note the Tux 2.0 Reference Manual is dated 2001.
serving a static file has three steps: decide which file to send, decide if to send the file, send the file. Now Tux did a really good job of sending the file, so so on deciding which file to send, and a lousy job of deciding if to send a file. The decisions are matter of policy and should be done in user space. Add sendfile and I can write a server that will be almost as good as tux in a short time, and add stuff without recompiling my kernel. maybe sql logging. just thinking about userspace sql calls being made from a kernel makes my eye twitch.
Tux isn't required anymore due to sendfile(). Nginx takes full advantage of this and IMO is one of the best web servers for static or non-static content. I've found memory problems with lighttpd, ymmv.
The whole purpose of CDN's is that it moves the 'web server' closer to the end users browser. This means less network hops and less round trip delay, without a large cost to you having to host multiple web servers around the world and using geo dns to send the user to the closest. Be aware tho as these web servers aren't in your control they could be overloaded and the benefit of less hops could be diminished if their network is overloaded. CDN's are usually targets of DDOS attacks and you might get caught up in something that has nothing to do with your content.
actually i don't know anything about http compression. i search google and got many code to implement http compression for asp.net web site. i just need to know what is the advantage of using http compression. does it reduce the page size or does it help page to download on client pc much faster.
i use one http module which implement http compression the code as follows.
enter link description here
enter link description here
just go to the link and tell me if i use those technique then my page size will be reduce and load faster. looking for advise.
thanks
Piskvor is right it is a simple answer to get by searching it.
If you are using IIS 7.5 (maybe 7.0 as well I am not 100% sure) then it is simple to turn on HTTP Compression through the server. If you turn on static and dynamic compression then you will see your responses will then be compressed.
Benefits include much smaller transmission size - so it will be sent much faster.
There is a tradeoff for the smaller page size but a higher CPU overhead (as the webserver will have to do more work to send the file) but for modern web servers this is more than reasonable.
If you are not using IIs7+ then you will have to implement the solutions as specified.
Does that help at all?
I have a LAN of 1000 clients with speeds of 1 GBPS.
One application hosted in IIS 7.5.
Fact: A megabyte response is transferred between the server and the client in no more than 30 miliseconds. The connection is very fast.
Fact: Some clients have older PCs (windows xp, ie7, pentium4).
I think that dynamic compression is not needed in this case, becuase the problem is not the bandwidth but the clients computer performance.
Do you recommend to disable compression?
My pages have too much javascript. In every post I refresh the page with javascript, ajax and json. In some cases when the HTML is too big, the browser gets a little bit unresponsible. I think that compression is causing this problem.
any comments?
A useful scenario for compression is when you have to pay for the bandwith and would like to speed up the download of large pages, but this creates a bit of work for the client having to uncompress the data before serving it.
Turn it off.
You don't need it for serving pages over a high-speed LAN.
Definitely don't think you need the compression. But you are shooting in the dark here -- get yourself a http debugger such as the one included in google chrome and see what parts of the pages are slow.
I have a slowly evolving dynamic website served from J2EE. The response time and load capacity of the server are inadequate for client needs. Moreover, ad hoc requests can unexpectedly affect other services running on the same application server/database. I know the reasons and can't address them in the short term. I understand HTTP caching hints (expiry, etags....) and for the purpose of this question, please assume that I have maxed out the opportunities to reduce load.
I am thinking of doing a brute force traversal of all URLs in the system to prime a cache and then copying the cache contents to geodispersed cache servers near the clients. I'm thinking of Squid or Apache HTTPD mod_disk_cache. I want to prime one copy and (manually) replicate the cache contents. I don't need a federation or intelligence amongst the slaves. When the data changes, invalidating the cache, I will refresh my master cache and update the slave versions, probably once a night.
Has anyone done this? Is it a good idea? Are there other technologies that I should investigate? I can program this, but I would prefer a configuration of open source technologies solution
Thanks
I've used Squid before to reduce load on dynamically-created RSS feeds, and it worked quite well. It just takes some careful configuration and tuning to get it working the way you want.
Using a primed cache server is an excellent idea (I've done the same thing using wget and Squid). However, it is probably unnecessary in this scenario.
It sounds like your data is fairly static and the problem is server load, not network bandwidth. Generally, the problem exists in one of two areas:
Database query load on your DB server.
Business logic load on your web/application server.
Here is a JSP-specific overview of caching options.
I have seen huge performance increases by simply caching query results. Even adding a cache with a duration of 60 seconds can dramatically reduce load on a database server. JSP has several options for in-memory cache.
Another area available to you is output caching. This means that the content of a page is created once, but the output is used multiple times. This reduces the CPU load of a web server dramatically.
My experience is with ASP, but the exact same mechanisms are available on JSP pages. In my experience, with even a small amount of caching you can expect a 5-10x increase in max requests per sec.
I would use tiered caching here; deploy Squid as a reverse proxy server in front of your app server as you suggest, but then deploy a Squid at each client site that points to your origin cache.
If geographic latency isn't a big deal, then you can probably get away with just priming the origin cache like you were planning to do and then letting the remote caches prime themselves off that one based on client requests. In other words, just deploying caches out at the clients might be all you need to do beyond priming the origin cache.
I have a web application where the client will be running off a local server (i.e. - requests will not be going out over the net). The site will be quite low traffic and so I am trying to figure out if the actual de-compression is expensive in this type of a system. Performance is an issue so I will have caching set up, but I was considering compression as well. I will not have bandwidth issues as the site is very low traffic. So, I am just trying to figure out if compression will do more harm than good in this type of system.
Here's a good article on the subject.
On pretty much any modern system with a solid web stack, compression will not be expensive, but it seems to me that you won't be gaining any positive effects from it whatsoever, no matter how minor the overhead. I wouldn't bother.
When you measured the performance, how did the numbers compare? Was it faster when you had compression enabled, or not?
I have used compression but users were running over a wireless 3G network at various remote locations. Compression made a significant different to the bandwidth usage in this case.
For users running locally, and with bandwidth not an issue, I don't think it is worth it.
For cachable resources (.js, .html, .css) files, I think it doesn't make sense after the browser caches these resources.
But for non-cachable resources (e.g. json response) I think it makes sense.