[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