There are two key players: the publisher (web server), and the consumer (web browser, web services consumer). It all depends on the abilities of the consumer to be capable of handling compressed content. You can exclude certain client types, which is sent to the web server in the request header, from receiving compressed content.
Axton Grams On Wed, Oct 8, 2008 at 11:48 AM, Grooms, Frederick W <[EMAIL PROTECTED]> wrote: > My question would be ... "How will this affect Web Services?" > > Of course with any change like this the motto is: Test, Test, Test > > Fred > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Axton > Sent: Wednesday, October 08, 2008 10:17 AM > To: [email protected] > Subject: Re: Web compression for Remedy mid-tier > > I changed the settings, restarted tomcat, logged in and hit the home > page, logged out, then logged back in and hit the home page. The > timings are from the second login to the complete load of the home > page. > > 2.09 seconds without compression > 2.66 seconds with > compression="on" > compressionMinSize="2048" > noCompressionUserAgents="gozilla, traviata" > compressableMimeType="text/js" > 2.66 seconds with > compression="on" > compressionMinSize="2048" > noCompressionUserAgents="gozilla, traviata" > > compressableMimeType="text/html,text/xml,text/plain,application/xml,imag > e/bmp,application/x-javascript,text/css" > 4.1 seconds with > compression="on" > compressionMinSize="2048" > noCompressionUserAgents="gozilla, traviata" > compressableMimeType="text/html,text/xml" > > The results seem a bit erratic. > > Env info: > Solaris 9 > Oracle 11g local > Oracle 10gr2 instant client > tomcat 6.0.18 > firefox with firebug > > In looking that the files sent across the wire, it seems the the > following mime types are commonly used for files greater than 2k: > text/html > text/plain > image/png > application/xml > image/jpeg > > You should take a look at firebug for firefox; it will show you the > mime type of every get/post to the server in the response headers. > > Axton > > On Tue, Oct 7, 2008 at 11:48 AM, Doug Blair <[EMAIL PROTECTED]> wrote: >> ** So, while you are wondering who will answer your next support call > and/or >> watching your stock tank, here's something that I have been > experimenting >> with: web compression. It's built into most browsers and web servers, > and >> by default it's turned off. Turning it on can really make a big > difference >> over longer, slower network connections. >> >> Here's what I have learned so far, and I'd really like to know if this >> results in any improved web performance at other sites. If you try > this >> please report your results (but trim all this text out to keep the > clutter >> down)... >> >> >> Turning on compression in the web-server used for Remedy mid-tier has >> produced a dramatic speedup at our site. I'm really not sure why this > isn't >> a recommended configuration, except that the compression will consume > some >> horsepower on the web server and decompression will use a few cycles > on the >> end user desktop. If your end-to-end times across the network are more > than >> a couple of seconds, it's probably worth testing at your site. >> >> Here are the steps to follow for Apache/tomcat 5.5.xx on Solaris. > These >> should also work for Apache/tomcat on Linux and HP and AIX, but I > haven't >> tested these other platforms. There's a link to instructions for > Windows IIS >> at the bottom. >> >> "tomcat" in a directory or path name refers to the installation > directory >> for Apache/tomcat. On my system this is /opt/ar/apache-tomcat-5.5.20, > and >> we've aliased that to just /opt/ar/tomcat. >> >> First, on your Apache/tomcat server, locate tomcat/conf/server.xml. > This >> configuration file has a stanza for each of the connectors your web > server >> is running, and you'll find one defined for port 8443, 8080, etc. >> Incidentally, you can change those to port 443 (secure) or port 80 and > get >> rid of the 8080 on your URL, or you can just duplicate the 8080 > stanza, >> changing the port number to just 80, and it will work either way, > assuming >> that you don't have anything else running on port 80. >> >> Find this text in tomcat/conf/server.xml: >> >> <!-- Note : To use gzip compression you could set the following > properties : >> >> compression="on" >> compressionMinSize="2048" >> noCompressionUserAgents="gozilla, traviata" >> compressableMimeType="text/html,text/xml" >> >> And add it to each of the stanzas for a port, so they look like this: >> >> <!-- Define a non-SSL HTTP/1.1 Connector on port 8080 --> >> <Connector port="8080" maxHttpHeaderSize="8192" > URIEncoding="UTF-8" >> maxThreads="150" minSpareThreads="25" > maxSpareThreads="75" >> enableLookups="false" redirectPort="8443" > acceptCount="100" >> connectionTimeout="20000" disableUploadTimeout="true" >> compression="on" compressionMinSize="2048" >> noCompressionUserAgents="gozilla, traviata" >> compressableMimeType="text/html,text/xml"/> >> >> There will probably be several stanzas, and I don't see anything wrong > with >> turning compression on for all of them. The compressMinSize setting > says >> that you need at least 2k worth of data before it's worthwhile > compressing >> it. You can adjust this value if you think it's necessary, but leave > it >> alone for now. In most cases you'll just add the last three lines to > an >> existing stanza. Be careful about the /> at the end. You'll need to > remove >> the /> on the last line of the existing stanza and make sure it > appears as >> the last thing in your new stanza. >> >> You could restart tomcat at this point on Windows and compression > would >> start working. >> >> If you are on Unix/linux there's another step (and this I learned the > hard >> way with a lot of googling). >> >> The Apache 5-5.x distributions truncate a bunch of filenames when they > are >> gunzipped on Unix hosts. The files are in >> >> tomcat/webapps/servlets-examples/WEB-INF/classes/compressionFilters >> >> and if they are broken they will look like this: >> >> total 58 >> 2 drwxr-xr-x 2 root root 512 Oct 2 11:41 . >> 2 drwxr-xr-x 7 root root 1024 Oct 2 15:21 .. >> 16 -rw-r--r-- 1 root root 7438 Sep 12 2006 >> CompressionFilter. >> 4 -rw-r--r-- 1 root root 1815 Sep 12 2006 >> CompressionFilterT >> 18 -rw-r--r-- 1 root root 8877 Sep 12 2006 >> CompressionRespons >> 16 -rw-r--r-- 1 root root 7920 Sep 12 2006 >> CompressionServlet >> or perhaps like this: >> total 66 >> 2 drwxr-xr-x 2 root root 512 Jun 25 2007 . >> 2 drwxr-xr-x 17 root root 512 Jun 25 2007 .. >> 8 -rw-r--r-- 1 root root 4025 Sep 12 2006 >> CompressionFilter.class >> 16 -rw-r--r-- 1 root root 7440 Sep 12 2006 >> CompressionFilter.java >> 4 -rw-r--r-- 1 root root 1815 Sep 12 2006 >> CompressionFilterTestSe >> 18 -rw-r--r-- 1 root root 8879 Sep 12 2006 >> CompressionResponseStre >> 16 -rw-r--r-- 1 root root 7922 Sep 12 2006 >> CompressionServletRespo >> >> They should look like this. Notice the longer file names: >> total 88 >> 2 drwxr-xr-x 2 root root 512 Oct 2 15:22 . >> 2 drwxr-xr-x 7 root root 1024 Oct 2 15:21 .. >> 8 -rw-r--r-- 1 root root 4025 Aug 28 22:10 >> CompressionFilter.class >> 16 -rw-r--r-- 1 root root 7626 Aug 28 22:10 >> CompressionFilter.java >> 4 -rw-r--r-- 1 root root 1665 Aug 28 22:10 >> CompressionFilterTestServlet.class >> 4 -rw-r--r-- 1 root root 1974 Aug 28 22:10 >> CompressionFilterTestServlet.java >> 10 -rw-r--r-- 1 root root 4354 Aug 28 22:10 >> CompressionResponseStream.class >> 20 -rw-r--r-- 1 root root 9318 Aug 28 22:10 >> CompressionResponseStream.java >> 8 -rw-r--r-- 1 root root 3838 Aug 28 22:10 >> CompressionServletResponseWrapper.class >> 14 -rw-r--r-- 1 root root 7114 Aug 28 22:10 >> CompressionServletResponseWrapper.java >> >> To fix, go get the current apache/tomcat 5-5-xx distribution from the >> download page at http://tomcat.apache.org, and unzip it on >> your Windows desktop. You don't actually need to unzip the whole > thing, >> just navigate to the compressionFilters folder and extract these 8 > files >> into another folder on your desktop, then FTP them to your web server > and >> put them into: >> >> tomcat/webapps/servlets-examples/WEB-INF/classes/compressionFilters >> It's probably a good idea to move the existing compressionFilters > directory >> to compressionFilters.original just in case. I don't know a lot about >> tomcat, but I think you could put these in WEB-INF/classes under any > app and >> they would work. tomcat just has to be able to find them somewhere, > and on >> my server the jsp-examples and servelet-examples apps are still > active. >> >> THEN >> >> go to tomcat/bin and run shutdown.sh, and then startup.sh >> >> THEN >> >> go to your desktop web browser and login to the Remedy page. You will >> probably want to exercise recaching all the pages on 7.0.x or earlier. >> >> THEN go tell your friends that it's working! >> >> Turning on compression for IIS on Windows 2003 is discussed here: >> > http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/I > IS/d52ff289-94d3-4085-bc4e-24eb4f312e0e.mspx?mfr=true >> >> I don't have an IIS setup at the moment, but it looks pretty >> straightforward. >> >> The time to display the Home Page is about 5 seconds in my current >> production system, and under 3 seconds on my compression test system. > Home >> Page click to one of our local apps is 7 seconds in current > production, 3 >> seconds in compressed system, with identical web servers and in the > same web >> browser on different tabs. The worst case at our site is about a > minute from >> Chicago to Tel Aviv (via a very weird network path) and after > compression >> it's about 12 seconds. There are similar speed-ups in initial drawing > many >> of the Remedy screens, not quite as big a difference in navigating > between >> records on a results list. Of course, any improvement you see will > depend on >> the configuration of your networks. >> >> Thanks to Norman Dignard for correspondence that helped me to resolve > the >> Unix gunzip file name issue. >> >> Let me know how it works... >> >> Doug >> >> >> Doug Blair >> Orbitz Worldwide >> [EMAIL PROTECTED] >> +1 312-260-2243 office >> +1 224-558-5462 mobile > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
