[Mediawiki-l] 100% CPU runaway with filecache in 1.3.0beta6
Rene Pijlman
rene at lab.applinet.nl
Sun Aug 8 14:56:04 UTC 2004
Rene Pijlman:
>Brion Vibber:
>>Found the problem. It seems that the buffer is being passed by reference
>>on PHP 4.1; the variable is modified by the function and all goes to
>>hell. Making a copy to operate on gets things working.
>
>This solves the runaway, but it's not working correctly yet.
BTW it works fine now with
$wgUseGzip = false;
in LocalSettings.php. The generic caching problem is fixed by
Brion's patch, a compressed caching problem remains.
>I've looked at the headers with wget -S, and there's no:
>
> Content-Encoding: gzip
Correcting myself...
I forgot that wget by default sends a different Accept-Encoding
header. When I run it with:
wget -S --header='Accept-Encoding: gzip, deflate' url
the headers look OK:
1 HTTP/1.1 200 OK
2 Date: Sun, 08 Aug 2004 14:39:31 GMT
3 Server: Apache/1.3.26 (Unix) Debian GNU/Linux
mod_python/2.7.8 Python/2.1.3 PHP/4.1.2
4 X-Powered-By: PHP/4.1.2
5 Vary: Accept-Encoding
6 Expires: -1
7 Cache-Control: private, must-revalidate, max-age=0
8 Last-modified: Sat, 7 Aug 2004 22:51:25 GMT
9 Content-Encoding: gzip
10 Content-Length: 1803
11 Keep-Alive: timeout=15, max=100
12 Connection: Keep-Alive
13 Content-Type: text/html; charset=iso-8859-1
14 Content-Language: nl
... and wget stores the gzipped data in a file (that's correct I
guess). With zcat it looks fine.
The question remains: why don't Firefox and IE uncompress the
data before rendering...
--
Regards / Groeten, http://www.leren.nl
René Pijlman http://www.applinet.nl
More information about the MediaWiki-l
mailing list