something apparently went wrong on zedler last night, but i don't have time
to piece together what it was from IRC scrollback (and no-one's let me know
what happened), and MySQL replication is still broken.
could someone please tell me what happened so i can fix it (or else fix it
if multiple people will perform root tasks on zedler, i think they should at
the minimum be logged either to this mailing list or the Wikimedia server
admin log (https://wikitech.leuksman.com/view/Server_admin_log).
(having said that, it's nice to know that i don't have to fix everything
myself now :-)
We have not so much traffic on the server so we can make the traffic faster
for user with slow downlinks.
My page is about 37kb in size. With mod_geflate i only have 7kb.
# Insert filter
# Netscape 4.x has some problems...
BrowserMatch ^Mozilla/4 gzip-only-text/html
# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4\.0 no-gzip
# MSIE masquerades as Netscape, but it is fine
# BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
mod_setenvif up to Apache 2.0.48
# the above regex won't work. You can use the following
# workaround to get the desired effect:
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
# Don't compress images
SetEnvIfNoCase Request_URI \
\.(?:gif|jpe?g|png)$ no-gzip dont-vary
# Make sure proxies don't deliver the wrong content
# Header append Vary User-Agent env=!dont-vary
Are there any arguments against switching to PHP 5? I use the SimpleXML
functions for parsing config files because XML is much more flexible (of
course you don't want to parse MediaWiki XML dumps with PHP!).
i was looking at memory usage on zedler recently, and discovered that grant
tables are using a significant amount of memory. i have implemented a
better solution, but as a side-effect, names of databases are changing.
from now on, each database X should be accessed as X_p (e.g.: "enwiki_p").
the old names will stop working shortly (sooner rather than later, since i
would like to reclaim the wasted memory).
also, the "rc_filtered" and "ar_filtered" tables will be known as
"recentchanges" and "archive" instead.
this will free about 2GB of RAM to be used by InnoDB, which should improve