From keith@instone.org Mon Nov 6 09:43:55 2000 Received: from mail.acm.org (mail.acm.org [199.222.69.4]) by turing.acm.org (8.9.2/8.9.2) with ESMTP id JAA00616 for ; Mon, 6 Nov 2000 09:43:54 -0500 (EST) Received: from instone.org (instone.org [161.58.216.245]) by mail.acm.org (8.9.3/8.9.3) with ESMTP id JAA31800; Mon, 6 Nov 2000 09:43:53 -0500 Received: from keithlatitude ([198.173.253.94]) by instone.org (8.8.8) id HAA13951; Mon, 6 Nov 2000 07:43:59 -0700 (MST) Message-ID: <016101c04800$514bdce0$5b00a8c0@keithlatitude> From: "Keith Instone" To: Subject: response time Date: Mon, 6 Nov 2000 09:46:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Status: O Thanks for the UW plug. Here is the "official" technical info on HTTP performance, but it does not have a usability slant. Have not seen anything that ties the back end of HTTP to usability, thus nothing at UW on it. You should probably write it!! http://www.w3.org/Protocols/HTTP/Performance/Overview.html Here is where the rantings about "speed" is, not sure if you found them: http://usableweb.com/topics/000778-0-0.html But nothing technical like what you talk about. Many years ago, I had an idea to write an article (like the one at http://www.w3j.com/5/s3.instone.html) for the WWW Journal about HTTP and usability, but they folded and I got busy. Back then I read the spec for 1.1 at http://www.w3journal.com/4/s3.wong.html and http://www.w3journal.com/4/s3.fielding.html and saw some possibilities. Somewhere at home is a copy of that issue with post-it notes for all of the usability implications I saw in those articles. See ya at CUU, maybe talk about this some more. Keith From owner-chi-web@ACM.ORG Mon Nov 6 10:03:50 2000 Received: from mail.acm.org (mail.acm.org [199.222.69.4]) by turing.acm.org (8.9.2/8.9.2) with ESMTP id KAA28446 for ; Mon, 6 Nov 2000 10:03:49 -0500 (EST) Received: from mail ([199.222.69.4]) by mail.acm.org (8.9.3/8.9.3) with ESMTP id KAA42308; Mon, 6 Nov 2000 10:00:32 -0500 Received: from ACM.ORG by ACM.ORG (LISTSERV-TCP/IP release 1.8d) with spool id 6898 for CHI-WEB@ACM.ORG; Mon, 6 Nov 2000 10:00:29 -0500 Approved-By: keith@INSTONE.ORG Received: from turing.acm.org ([199.222.69.20]) by mail.acm.org (8.9.3/8.9.3) with ESMTP id AAA77322 for ; Mon, 6 Nov 2000 00:23:25 -0500 Received: (from perlman@localhost) by turing.acm.org (8.9.2/8.9.2) id AAA28884 for chi-web@acm.org; Mon, 6 Nov 2000 00:23:25 -0500 (EST) Message-ID: <200011060523.AAA28884@turing.acm.org> Date: Mon, 6 Nov 2000 00:23:25 -0500 Reply-To: Gary PERLMAN Sender: "ACM SIGCHI WWW Human Factors (Open Discussion)" From: Gary PERLMAN Subject: HTTP/1.1 compression and response time To: CHI-WEB@ACM.ORG Status: O I know this topic is not "flashy", but response time is a time-tested usability concern. Call me a "compressionate conservative". We are planning on adding HTTP/1.1 compression to our servers. So far, the results have been astounding. Compression time on our end is insignificant, and arguably a net gain hopping on our internal network. For HTML pages, which contain a lot of redundancy, the compression ratio range from 70-90% and higher. One page, which has 85K of text, is delivered in less that 8K bytes. For users with a slow connection, of which we have many, especially outside the US, the difference for a 56K connection on the above page is (assuming 6K bytes per second, which is optimistic) a reduction of transmission time from 14.2 seconds to 1.33 seconds. What is remarkable to me is that chi-web has not discussed this, and usableweb.com gets only two hits for "response time" (one being a Jakob Nielsen Alertbox article from 1995 with a section on response time). A google search for "http compression" will get you good pointers. We use Apache, for which there is free compression code. Besides the plug for what appears to be a big win for users, I also have a concern. Is this too good to be true? Do people know of any problems with running HTTP/1.1 compression? I know some issues already: * our regression testing software catches what a browser would see, and changing to gzipped data from HTML caused a big difference and required a change. * some browsers send HTTP_ACCEPT_ENCODING with gzip, even though they can not handle gzip (we are compiling a list). And yes, I already know: * most compressed image formats do not get compressed * other redundant languages (e.g., XML) compress very well Please send any bad experiences to me, and I will summarize. In this case, no news will be good news. Gary PERLMAN, OCLC Online Computer Library Center 6565 Frantz Road, Dublin, Ohio 43017 USA perlman@acm.org http://www.acm.org/~perlman/ --------------------------------------------------------- About CHI-WEB: http://www.acm.org/sigchi/web/chi-web.html --------------------------------------------------------- From perlman@oclc.org Mon Nov 6 10:41:11 2000 Received: from mail.acm.org (mail.acm.org [199.222.69.4]) by turing.acm.org (8.9.2/8.9.2) with ESMTP id KAA24800 for ; Mon, 6 Nov 2000 10:41:10 -0500 (EST) Received: from oa1-server.oa.oclc.org (oa1-server.oa.oclc.org [132.174.29.60]) by mail.acm.org (8.9.3/8.9.3) with ESMTP id KAA47668 for ; Mon, 6 Nov 2000 10:41:04 -0500 Received: by oa1-server.oa.oclc.org with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Nov 2000 10:40:58 -0500 Message-ID: <72B89459DD2BD211B5CD0000F840094E02FE27EE@oa3-server.dev.oclc.org> From: "Perlman,Gary" To: "'perlman@acm.org'" Subject: FW: FW: HTTP Compression Speeds up the Web WebReference.com Date: Mon, 6 Nov 2000 10:40:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Status: O -----Original Message----- From: Hawk,Mickey Sent: Monday, October 23, 2000 1:34 PM To: Driscoll,Steve; Payne,Tim; Limes,Michael; Vu,Jim; Hermance-Moore,Robin; Miller,Terry; Smith,Steve(SMS); Fought,Tom; Penka,Jeff; Whitney,Dan; Perlman,Gary; Norman,Phil; Fitch,James Cc: Skopin,Rich; Hysell,Debbie; Lewis,Deb Subject: RE: FW: HTTP Compression Speeds up the Web WebReference.com Gary, Phil, or James, can you address Steve's questions related to this? Steve, I would think that, since client-side scripting elements are becoming a larger part of the pages we send, that they would benefit from compression. Also, if it "does no harm", seems it would be worthwhile to pursue regardless. -----Original Message----- From: Driscoll,Steve Sent: Monday, October 23, 2000 1:25 PM To: Hawk,Mickey; Payne,Tim; Limes,Michael; Vu,Jim; Hermance-Moore,Robin; Miller,Terry; Smith,Steve(SMS); Fought,Tom; Penka,Jeff; Whitney,Dan Cc: Skopin,Rich; Hysell,Debbie; Lewis,Deb Subject: RE: FW: HTTP Compression Speeds up the Web WebReference.com I hesitate to make commitments for anyone, but my understanding of our roles since the re-org would make Dan and Steve Smith would be the people for this. But there's some issues to consider: Let's quantify the real benefits. We need numbers, not anecdotes. Gary gives an excellent explanation below of how to measure response time. Are we collecting stats on FirstSearch to show the benefits of compression? Also, how well does it work with GIF,s JPG's, PDF's and ZIP files? My experience is that compression does little for these filetypes and they make up the bulk of files with long "service times". I'm attaching part of last Friday's performance report for www.oclc.org for reference: ---- Statistical Analysis of Performance for 20001020 ----- Average time to service request = 0.80 seconds Std Deviation = 1.22 seconds Upper control Limit = 4.45 seconds Total transactions ( including errors ) = 239,552 Transactions in analysis, ( errors not included ) = 237,906 Transactions above the control limit = 382 Transactions below the control limit = 18,171 ---- Service time in seconds for those URL's above the control limit ---- Average Max Count URL 302.0 302.0 4 url = http://www.oclc.org/cgi-oclc/fs-sample.scr 285.4 1676.0 24 url = http://www.oclc.org/esd/passport/pp110a35.exe 223.6 867.0 16 url = http://www.oclc.org/webart/wnt15e.exe 222.0 652.0 3 url = http://www.oclc.org/oclc/presres/micrographic/manuscriptquest.htm 192.8 496.0 10 url = http://www.oclc.org/esd/ill/il20035.exe 189.1 1285.0 29 url = http://www.oclc.org/esd/catme/cm11135.exe 174.4 1202.0 7 url = http://www.oclc.org/cgi-oclc/fs5d.scr 137.3 426.0 6 url = http://www.oclc.org/esd/label/lab12035.exe 103.3 291.0 3 url = http://www.oclc.org/oclc/man/ifla/ifla.ppt 100.2 688.0 17 url = http://www.oclc.org/dewey/products/newDot_marks_the_spot.exe <<< rest of report deleted for brevity >>> > -----Original Message----- > From: Hawk,Mickey > Sent: Monday, October 23, 2000 1:03 PM > To: Driscoll,Steve; Payne,Tim; Limes,Michael; Vu,Jim; > Hermance-Moore,Robin; Miller,Terry; Smith,Steve(SMS); Fought,Tom; > Penka,Jeff > Cc: Skopin,Rich; Hysell,Debbie; Lewis,Deb > Subject: FW: FW: HTTP Compression Speeds up the Web WebReference.com > Importance: High > > > Thanks, Phil, for forwarding this string. > > I originally sent this article (see bottom) to a small group > I knew that might find it useful. It seems to have worked so > well for FirstSearch, that I thought I would pass it on to a > broader distribution. > > Steve, has anyone addressed this for our main external webs? > > Mick > > -----Original Message----- > From: Norman,Phil > Sent: Monday, October 23, 2000 8:47 AM > To: Hawk,Mickey > Subject: FW: FW: HTTP Compression Speeds up the Web WebReference.com > > > FYI > > Who would be looking at this for the OCLC home page? Steve Driscoll? > > -----Original Message----- > From: Perlman,Gary > Sent: Friday, October 20, 2000 7:51 PM > To: Perlman,Gary; Fitch,James; Norman,Phil > Cc: Teets,Mike > Subject: RE: FW: HTTP Compression Speeds up the Web WebReference.com > > > I tried it from home. It's great. It feels like about a 50% > reduction of response time. If quality is judged by the user, > then our method of measuring response time is more > OCLC-cenered than user-centered. > Time A - user sends request > Time B - OCLC gets request > Time C - OCLC sends response > Time D - user gets response > Subjective response time is based on D-A. We do not have any > control over B-A, but that tends not to be too much data. We > now measure response time as C-B, but much of D-A is > transmission time D-C. With an 80% drop (sometimes 90%) in > response time for D-C, our users' judgement of quality will > be much higher. This is so obvious in hindsight, it is > painful. But it's a good kind of pain. > > I'm thinking about the OCLC Periodical Title Finder, which > regularly sends out pages in the 100K+ range, and what a > difference it would make to those users. Can the enhancement > be applied to the main OCLC site, and other OCLC services? > > -----Original Message----- > From: Perlman,Gary > Sent: Friday, October 20, 2000 12:54 PM > To: Fitch,James; Norman,Phil; Perlman,Gary > Cc: Teets,Mike > Subject: RE: FW: HTTP Compression Speeds up the Web WebReference.com > Importance: High > > > This is incredibly good news from James! > > I have to admit that I have not tried this, even though I can > connect from home. I keep on forgetting. But based on the > stats that James showed me today, I think this is a HUGE > benefit to many of our users. I think it will be the most > significant new "feature" we release in the next few months, > and it is directed at the core goal of OCLC to reduce > information costs. I think we should pump it up for all it is worth. > > The stats basically show an 80% reduction in bytes > transmitted for negligible processing costs on our end, and > depending on how many hops the data takes going out of OCLC, > it could have performance BENEFITS instead of costs. The > change can only be handled by some browsers (MSIE 4+ and > Netscape 4.5+), and its effects are mainly noticeable for low > speed connections (e.g., 28K or 56K). I suspect that many of > the low speed connections may also have older browsers > (notably Netscape 4.08), but this is the sort of change that > could motivate sites to upgrade. > > Consider this scenario. A user searches WorldCat for dog. > The first two pages of results average 37K bytes, and these > get compressed down to about 6K. At 28.8K, the download time > is about 12 seconds versus 2. Add on the OCLC response time > of say 2 seconds, we are talking about 14 seconds dropping > down to 4 seconds. Paging through pages of records could > drop, to the user, from 13 to 3 seconds. If quality is > determined by the user, then our response time measures miss > most of the big picture for many users. At 56K, the gains > are smaller: 6+2 seconds get reduced to 1+2, but it's still > half the time. Some of our screens are much larger, e.g., > all databases is about 50-85K, depending on how many > databases are subscribed. For 60K bytes cut down to 18K, > users will see their download time cut from 20 seconds to 6 > seconds at 28.8K or from 10 seconds down to 3 for 56K. > > Our international users will love this, especially if they > pay by the packet, because it will reduce information costs > in time and money. If we start delivering 16bit unicode > characters, the compression will mean that there will be > basically no negative impact on transmission time. > > Trying it out from development, with our very fast > connection, it was still noticeable to me which server had > compression. It felt like 1-2 seconds per screen, even > though it might only have been part of a second. > > This feature could cause some problems for some users, > although it is not supposed to, and it may be prudent to > release it separate from a maintenance release, or at least > not announce it until we are sure we are not getting reports > of garbage on users screens. > > -----Original Message----- > From: James Fitch [mailto:fitchj@oclc.org] > Sent: Tuesday, October 17, 2000 5:03 PM > To: Norman,Phil; Perlman,Gary > Subject: Re: FW: HTTP Compression Speeds up the Web WebReference.com > > > I have been playing around with the http compression stuff > described below and it looks interesting. I have set up two web > servers in my test environment (one with compression and one > without) so that we can test them side by side. The effect is > not noticeable unless you are using a slow connection (it > seems to make a difference over my 56K modem). If you would like > to, you can test it out at http://risc14.dev.oclc.org:42580 > and http://risc14.dev.oclc.org:42581. I was bringing up two > browsers side by side and doing the same transactions, one > after the other, and trying to count to see how long each took. > > For this to work you have to have a browser that supports > HTTP 1.1 compression witch should be IE > version 4 or Netscape > > version 4.5. However I did see that IE 4.5 for the Mac does > not have this support. > > Let me know what you think if you get a chance to test it out. > > > "Norman,Phil" wrote: > > > FYI > > > > -----Original Message----- > > From: Hawk,Mickey > > Sent: Friday, October 13, 2000 2:42 PM > > To: Limes,Michael; Payne,Tim; Vu,Jim; Driscoll,Steve; Norman,Phil > > Subject: HTTP Compression Speeds up the Web WebReference.com > > > > fyi. Mick > > > > http://webreference.com/internet/software/servers/http/compression/ > > > > > -------------------------------------------------------------- > ---------- > > > > HTTP Compression Speeds up the Web > WebReference.com.urlName: HTTP Compression Speeds up the Web > WebReference.com.url > > > Type: unspecified type (application/octet-stream) > From andrew@tki.org.nz Mon Nov 6 10:48:32 2000 Received: from mail.cwa.co.nz (cwa.co.nz [203.96.59.39]) by turing.acm.org (8.9.2/8.9.2) with SMTP id KAA31371 for ; Mon, 6 Nov 2000 10:48:30 -0500 (EST) Received: (qmail 19017 invoked from network); 6 Nov 2000 15:47:52 -0000 Received: from sub.internal.cwa.co.nz (10.10.10.35) by mx.internal.cwa.co.nz with SMTP; 6 Nov 2000 15:47:52 -0000 Date: Tue, 7 Nov 2000 04:47:50 +1300 (NZDT) From: Andrew McNaughton X-Sender: andrew@sub.internal.cwa.co.nz To: Gary PERLMAN cc: CHI-WEB@ACM.ORG Subject: Re: HTTP/1.1 compression and response time In-Reply-To: <200011060523.AAA28884@turing.acm.org> Message-ID: Priority: Normal MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 6 Nov 2000, Gary PERLMAN wrote: > We are planning on adding HTTP/1.1 compression to our servers. > So far, the results have been astounding. Compression time > on our end is insignificant, and arguably a net gain hopping > on our internal network. For HTML pages, which contain a lot > of redundancy, the compression ratio range from 70-90% and higher. > One page, which has 85K of text, is delivered in less that 8K bytes. > For users with a slow connection, of which we have many, especially > outside the US, the difference for a 56K connection on the above > page is (assuming 6K bytes per second, which is optimistic) > a reduction of transmission time from 14.2 seconds to 1.33 seconds. This fails to account for the fact that almost all modem connections are already using compression built into the modem. I expect you will see some gain but you should test the actual gains with a real modem. Andrew McNaughton -- Andrew McNaughton Te Kete Ipurangi: The Online Learning Centre andrew@tki.org.nz Ph: 64 4 382 6500 Fax: 64 4 382 6509 Mobile: 021 323 076 PO Box 19-098 Wellington, NZ http://www.tki.org.nz/ From andrew@tki.org.nz Mon Nov 6 11:40:38 2000 Received: from mail.cwa.co.nz (cwa.co.nz [203.96.59.39]) by turing.acm.org (8.9.2/8.9.2) with SMTP id LAA03400 for ; Mon, 6 Nov 2000 11:40:36 -0500 (EST) Received: (qmail 20194 invoked from network); 6 Nov 2000 16:40:07 -0000 Received: from sub.internal.cwa.co.nz (10.10.10.35) by mx.internal.cwa.co.nz with SMTP; 6 Nov 2000 16:40:07 -0000 Date: Tue, 7 Nov 2000 05:40:06 +1300 (NZDT) From: Andrew McNaughton X-Sender: andrew@sub.internal.cwa.co.nz To: CHI-WEB@ACM.ORG cc: Gary PERLMAN Subject: Re: HTTP/1.1 compression and response time Message-ID: Priority: Normal MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Note to Chi-web moderators - please substitute this for the message I just sent. It contains extra information. ------------------------------------------------------------------------- On Mon, 6 Nov 2000, Gary PERLMAN wrote: > We are planning on adding HTTP/1.1 compression to our servers. > So far, the results have been astounding. Compression time > on our end is insignificant, and arguably a net gain hopping > on our internal network. For HTML pages, which contain a lot > of redundancy, the compression ratio range from 70-90% and higher. > One page, which has 85K of text, is delivered in less that 8K bytes. > For users with a slow connection, of which we have many, especially > outside the US, the difference for a 56K connection on the above > page is (assuming 6K bytes per second, which is optimistic) > a reduction of transmission time from 14.2 seconds to 1.33 seconds. This fails to account for the fact that almost all modem connections are already using compression built into the modem. Also, a large part of the traffic is commonly images, which are already compressed. I expect you will see a significant gain, but not as dramatic as you suggest. I looked around a few pages on the topic. http://www.w3.org/Protocols/HTTP/Performance/Compression/PPP.html http://www.mozilla.org/projects/apache/gzip/ The first considers only HTML traffic, the later attempts to compare overall performance for a typical web session. I'd have to say I'm surprised by thenumbers in the w3.org page. There's very little difference between the saving in number of packets and the saving in time. This suggests that either the modem compression is almost entirely ineffective, or it's almost exactly balanced by the reduction of per-packet overhead. Andrew McNaughton -- Andrew McNaughton Te Kete Ipurangi: The Online Learning Centre andrew@tki.org.nz Ph: 64 4 382 6500 Fax: 64 4 382 6509 Mobile: 021 323 076 PO Box 19-098 Wellington, NZ http://www.tki.org.nz/ From perlman Mon Nov 6 11:46:22 2000 Received: (from perlman@localhost) by turing.acm.org (8.9.2/8.9.2) id LAA03680; Mon, 6 Nov 2000 11:46:19 -0500 (EST) From: Gary PERLMAN Message-Id: <200011061646.LAA03680@turing.acm.org> Subject: Re: HTTP/1.1 compression and response time To: andrew@tki.org.nz (Andrew McNaughton) Date: Mon, 6 Nov 100 11:46:18 -0500 (EST) In-Reply-To: from "Andrew McNaughton" at Nov 7, 0 04:47:50 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Status: O Good point. It may account for some unexpected lack of differences. I checked with a real modem, but only one (mine) connecting to who knows what we have at work (which may not support compression). I'll make sure to try some tests and point out your caveat. Gary > On Mon, 6 Nov 2000, Gary PERLMAN wrote: > > > We are planning on adding HTTP/1.1 compression to our servers. > > So far, the results have been astounding. Compression time > > on our end is insignificant, and arguably a net gain hopping > > on our internal network. For HTML pages, which contain a lot > > of redundancy, the compression ratio range from 70-90% and higher. > > One page, which has 85K of text, is delivered in less that 8K bytes. > > For users with a slow connection, of which we have many, especially > > outside the US, the difference for a 56K connection on the above > > page is (assuming 6K bytes per second, which is optimistic) > > a reduction of transmission time from 14.2 seconds to 1.33 seconds. > > This fails to account for the fact that almost all modem connections are > already using compression built into the modem. I expect you will see > some gain but you should test the actual gains with a real modem. > > Andrew McNaughton > > > > -- > Andrew McNaughton > Te Kete Ipurangi: The Online Learning Centre > andrew@tki.org.nz > Ph: 64 4 382 6500 > Fax: 64 4 382 6509 > Mobile: 021 323 076 > > PO Box 19-098 > Wellington, NZ > http://www.tki.org.nz/ > >