By definition of caching you're not going to see a sudden magical
increase in speed on your site. You need to enable it, and wait for
awhile so that the caches can get built up by people viewing the site
and start actually being used as the same things are viewed over. You
may also want to try an optcode cache like eAccelerator, APC, or xcache
if you don't already have one.
However, by your mention of the MessageCache and $wgUseDatabaseMessages,
the issue looks like it has to do something with the database queries
used to grab the messages.
~Daniel Friesen(Dantman) of:
-The Nadir-Point Group (
http://nadir-point.com)
--It's Wiki-Tools subgroup (
http://wiki-tools.com)
--Games-G.P.S. (
http://ggps.org)
-And Wikia ACG on
Wikia.com (
http://wikia.com/wiki/Wikia_ACG)
Neil Bird wrote:
In a nutshell, I've upgraded a previously
working 1.5.(1?) install to
1.12.0. It seemed to go smoothly, and everything's there with no
discernible errors, but pages are taking some 20 s. to come back.
I'm not running any caching, but there are 4 wikis on this [CentOS 5] box
running under Apache virtual servers, one at least of which has been 1.12.0
for a bit and doesn't show any slowness with no caching.
I've compared the LocalSettings.php files for the OK one and my slow one,
and there's nothing obviously different that might affect this.
Bizarrely, we have a development box alongside the production one which
ought to be identical (they actually both virtual boxes on the same hopst(s)
just to confuse matters), and my wiki runs at a decent rate on that one.
Same versions, I've copied the d/b across (mysqldump --add-drop-tables), and
compared the entire 'wiki' subdirs. No obvious diff.
The only advertised diff. between the production box and the dev. one is
that the production box uses SELinux.
*Also*, I have found that I can ‘remove’ the speed problem by using
“$wgUseDatabaseMessages = false;“ (from a google around the issue).
However, the MediaWiki docs imply that this would be obviated by using
caching, and I have tried memcached temporarily, and it seemed to make no
difference at all.
I'm now down to analysing a strace of a php session between the working
wiki and mine.
Just for completeness, here's a bit of my strace that displays a lag.
Note that I can find no ref. to ‘Revision.php’ in the strace of the working
one. Also, just prio to this there's mention of ‘MediaWikiBagOStuf...’ and
then ‘MessageCache::loa...’ in what I think is a channel to mysql. There's
no mention of MessageCache, bar one to the .php file, in the working strace.
Does anyone have any ideas about what I can look at next?
----
time(NULL) = 1214560045
lstat64("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/var/www", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/var/www/fwwiki", {st_mode=S_IFDIR|0770, st_size=4096, ...}) = 0
lstat64("/var/www/fwwiki/wiki", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
lstat64("/var/www/fwwiki/wiki/includes", {st_mode=S_IFDIR|0775,
st_size=12288, ...}) = 0
lstat64("/var/www/fwwiki/wiki/includes/Revision.php", {st_mode=S_IFREG|0664,
st_size=22430, ...}) = 0
open("/var/www/fwwiki/wiki/includes/Revision.php", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0664, st_size=22430, ...}) = 0
lseek(4, 0, SEEK_CUR) = 0
read(4, "<?php\n/**\n * @todo document\n */\n"..., 8192) = 8192
brk(0x8c54000) = 0x8c54000
read(4, "er = isset( $row[\'user\'] "..., 8192) = 8192
read(4, "o external storage if required\n\t"..., 8192) = 6046
read(4, "", 8192) = 0
read(4, "", 8192) = 0
close(4) = 0
nanosleep({1, 213780000}, NULL) = 0
<snip lots of these>
nanosleep({1, 70533000}, NULL) = 0
access("/var/www/fwwiki/wiki/serialized/MessagesEn.ser", F_OK) = -1 ENOENT
(No such file or directory)
access("/var/www/fwwiki/wiki/languages/messages/MessagesEn.php", F_OK) = 0
stat64("/var/www/fwwiki/wiki/languages/messages/MessagesEn.php",
{st_mode=S_IFREG|0664, st_size=188674, ...}) = 0
time(NULL) = 1214560066