On Wed, 29 Sep 2004 16:30:51 -0400, HansH wrote
(in article <cjf61t$vd0$1@news.cistron.nl>):
> "Jonathan Brady" <jbrady.RemoveThis@removethisspamkiller.myfmail.com> schreef in
> bericht news:cjep7f0e1i@news1.newsguy.com...
>> On Tue, 28 Sep 2004 18:13:12 -0400, HansH wrote
>> (in article <cjcnlp$393$1@news.cistron.nl>):
>> I've removed the general deflate filter and set it to deflate only
>> text/html and text/plain and it's still exhibiting the same problem.
>
> That is, sending double zipped zips via php???
Yes, that problem is still manifesting itself. If the readers unzip the
downloaded file and unzip it, instead of getting a folder like they
should, they get another file with no extension. If they add .zip to its
name and unzip again, then they do get a folder with useable files in
it.
>> Plus it's not as efficient as the old apache 1.3/mod_gzip combination,
>> the bandwidth requirement is double what is was for the same content
>> even with a deflation setting of 9. For a site that delivers on average
>> 4 million pages per day, doubling the bandwidth is very costly.
> I hope this does not bother you too much
<font color=purple> > <a style='text-decoration: underline;' href="http://support.microsoft.com/default.aspx?scid=kb;en-us;Q312496</font" target="_blank">http://support.microsoft.com/default.aspx?scid=kb;en-us;Q312496</font</a>>
That is very interesting because not everybody is reporting the problem
and all those who are are IE users. I think we're on to something here,
although, the nature of the site's audience makes it impossible to
recommend that article to the readers themselves (they're mostly older
generation -- over 55).
Microsoft's recommendation of disabling compression is not an option.
The kicker, however, is that it didn't happen with apache 1.3/mod_gzip
combination.
>> And on a really fast machine (compared to the old one -- New is dual
>> Xeon 3.0 Ghz with a fast RAID and the old is a single Pentium III 866
>> Mhz with a single IDE Drive) the site hesitates and pauses a lot, even
>> when accessing pages through the LAN; simply inexplicable.
>
> Did you check the server log -not the logs of virtuals- for "server reached
> MaxClients setting"
It's nowhere near maximum users. So far I've narrowed down the glitches
in server response with header requests. When getting the status of css
and images to see if they've been modified, there is an inexplicable
delay, often few seconds. If the files are not in the browser's cache,
then they're delivered by the server promptly.
>> I've decided to go back to 1.3 and wait few years until apache 2 becomes
>> useable.
> Both are free as is the choice.
>
> If about all your pages are php parsed, have a peek at
<font color=purple> > <a style='text-decoration: underline;' href="http://nl.php.net/ob_start</font" target="_blank">http://nl.php.net/ob_start</font</a>>
> " In PHP 4.0.4, ob_gzhandler() was introduced to facilitate sending
> gz-encoded data to web browsers that support compressed web pages.
> ob_gzhandler() determines what type of content encoding the browser will
> accept and will return its output accordingly. "
>
> Brings a new opener too, it _*/might/*_ even be PHP _causing_ the double
> compression ...
Nothing was changed in the pages before moving them to the new setup, so
if it's the php code, then its interaction with the new software which
is apache 2.0.51 that is triggering the problem.
The exactly same code running on apache 1.3.31 and php 5.0.2 runs
flawlessly.
--
J Brady<!-- ~MESSAGE_AFTER~ -->
>> Stay informed about: mod_deflate config question