Why GZip is disabled in D7Some time later, Manfred Dillmann offered a solution (to be used at your own risk). This appears to enable GZip compression on all data served by the Domino HTTP task. As we have users who still insist on dialup connections, and in fact have investigated putting a proxy in front of Domino to compress HTTP traffic, this looked too good to be true.
It was.
Seemingly at random, the server started to crash. Intervals ranged from 4 minutes to nearly an hour but were typically 10-15 minutes. One part of the crash dump was pretty consistent indicated below by --> ... <--
############################################################ ### FATAL THREAD 54/60 [ nhttp: 1804: 952] ### FP=0x1274fc60, PC=0x0000006e, SP=0x1274fc50 ### stkbase=12750000, total stksize=262144, used stksize=944 ### EAX=0x1003ca54, EBX=0x0f290108, ECX=0x11d3d41c, EDX=0x021446da ### ESI=0x11d3d41c, EDI=0x1274fc70, CS=0x0000001b, SS=0x00000023 ### DS=0x00000023, ES=0x00000023, FS=0x0000003b, GS=0x00000000 Flags=0x00010212 Exception code: c0000005 (ACCESS_VIOLATION) ############################################################ --> [ 1] 0x0000006e (f290108,f290108,1003f7a8,0)<-- -->@[ 2] 0x100218cb nhttpstack.HTResponse::PostProcess+251 (0,f32ed37,0,434e442f)<-- @[ 3] 0x10024e9f nhttpstack.HTSession::StartRequest+991 (f32ed43,f32ed37,0,f32ed69) @[ 4] 0x1002c08f nhttpstack.HTWorkerThread::CheckForWork+399 (3,f32ed37,10029180,100291aa) @[ 5] 0x1002c5a8 nhttpstack.HTWorkerThread::ThreadMain+88 (f32ed37,0,0,0) @[ 6] 0x60105020 nnotes._ThreadWrapper@4+208 (0) @[ 7] 0x7c57b388 KERNEL32.CreateProcessW+310
Only one of the several web sites on the server in question seemed to cause this - the others worked without incident. We were able to prove this by disabling that one web site. The site in question is comprised mainly of bespoke databases many of which implement workflow and some of which have back end connectivity to back office systems. Which part of it objected to GZip compression is anyone's guess - no time to debug that now anyway. Disabling GZip appears to have corrected the problem.
The message - perhaps there is some method in IBM's apparent madness in hiding the GZip feature in the first place...
Category: Domino 7
Technorati: Domino 7
1. Jens Bruntt09/03/2006 10:30:23
Homepage: http://www.convergens.dk/jbr
I have been using Puakma Web Booster to do Gzip compression. It works.
You can install it on the Domino server, you let it answer on port 80, and you let Domino answer HTTP on some other port. All http traffic to the server now gets boosted.
2. Chris Linfoot09/03/2006 10:33:03
Well, yes. Probably safer than hacking Domino's native GZip which, like I said, has been hidden by IBM probably for very good reasons.
3. Wild Bill09/03/2006 11:30:06
Homepage: http://www.billbuchan.com
Most software developers attempt to put in "large" features but for reasons of time, usually dont "publish" them in the code until they're happy its right.
On a time-boxed development methodology such as the one the guys at Westford use, large architectural changes require multi-release updates. I suspect that this was high in the ND7 feature list, but wasnt considered stable enough for primetime. And so most of it got buried for good reason.
Dont get me wrong - its good to know that this stuff is in there and *may* at some point see the light of day. Even enabling it on a test server is cool.
But in terms of running production systems based on that ? No. Its not professional for a start.
And yes -there's lots of third party software (such as Webbooster to name another) and a bunch of hardware devices that do this. And do on the fly SSL encryption too - something thats very CPU intensive and a good candidate for shipping off a busy Domino server.
Just best practices, I guess.
---* Bill
4. Chris Linfoot09/03/2006 11:59:56
I agree.
No harm done here as the web sites affected were affected only for a brief period, are not mission critical anyway so a small amount of downtime is acceptable and serve a group of users who won't upgrade hardware, OS, browser or network bandwidth but are constantly asking for better performance.
On a more critical system than this I wouldn't have tried the experiment at all but the fact that others have used this without incident for long periods combined with the factors listed above tempted me to try it very briefly here.
As for a test server - did that. Works fine for long periods and with no incidents. It's only when real users put it to the test that it breaks. Why? Because some of the real users use unexpected OS and browser software (Win98/IE4 anyone?). And yes there are good business reasons to continue to permit this.
5. Kary Forth13/03/2007 18:51:15
Homepage: http://www.projectedge.com
After turning on gzip, the form data sent to the browser from the (fairly complicated) app I'm testing was decreased by just over 75% - 24KB to 6KB.
Measuring using Fiddler and Firebug, I found that the time Domino took to get it to the browser went from apx. 15ms uncompressed to around 6.9 seconds with Domino compressing it. Seems the server was gagging on something when gzipping. Suddenly, my LAN speed was modem like. Maybe it would have been beneficial over a slow connection, but it seems to me that there's a good reason for gzip functionality to be hidden.
Unable to post a comment? Please read this for a possible explanation...
- 
