#musicbrainz-devel

might be APC

CACHE_ACCEL

yeah, thats APC.

derwin: this is not about the main site, it's about the wiki

ah!

and yes, we do have caching on the main site, but it doesn't help as much as it should

long story with that, but anyway :)

on the wiki, you guys have hitcounters on, which are a pretty big performance hit: "This page has been accessed 1,255,649 times." <-- causes a db write on every page load

hm, that may be historical

and I wonder if anyone cares

unless you guys really want that, I'd recommend turning it off

(suspicion is nobody cares)

it's so unperformant that we're planning to remove it from MediaWiki in the next release

I didn't even know we had it :P

let's see, other weirdnesses we have

I'm not sure it's much use to us anyway

we have some stuff to hack in https support behind our reverse proxy, not sure if done correctly

we have an IsTrustedProxy hook, related

$wgDisableCounters = true;

some extra groups/permissions which IIRC didn't bring much complication

no more counters!

if someone complains I can worry about it, doubt anyone who doesn't read this will even notice :P

:D

do you guys have a recommended nginx config, btw?

hmm, I don't think so

I think I mostly just made something up that seemed to work properly

we have example configs to help setting up /wiki/, but this is in root :/

https://www.mediawiki.org/wiki/User:Aaron_Schul... is the list of things I usually go through when setting up a new wiki, there are probably a few more things in there we could try

I have a feeling I allow too many things to get passed to php-fpm (though doing better than apache is not very difficult)

OMG, the counters on the wiki have disappeared! I must open an OTHER ticket!

heh

which we'll furiously ignore? XD

Fine, I was cheating. ;-)

hm, only got wgMainCacheType, unsure if the others should be on

hehe

I hadn’t noticed if I hadn’t read here.

wgUseGzip isn't on, but nginx probably does most of that for me

there's a lot of easy stuff like http://wiki.musicbrainz.org/index.php?title=Med...

just change "{{SITENAME}}" to "MusicBrainz wiki"

but what if it changes?

heh

nobody will notice :P

haha

Are the counters 64 bit? :-p

chirlu`: http://stats.grok.se/en/201410/Main%20Page

haha I was just gonna say I wonder if it can even count that high

I always forget there's a main wp page.

ianmcorvidae: is the webserver user able to write to the filesystem? (or at least a part of it?) we could enable some extra file caching then

should be, I think

well, I mean, it writes to images I guess

also this is running ubuntu or debian right?

ubuntu 12.04, yes

Seems 32 bit wouldn’t be enough for 1.5 years.

you can install the 'php-wikidiff2' package for faster diff rendering

and presumably some localsettings bits

and set $wgExternalDiffEngine = 'wikidiff2'

chirlu`: btw, unrelated, but you totally confused me the other day by adding the first disc's disc id for that release in the time it took me to rip the second disc :P

Sorry. :)

it was amusing to imagine us simultaneously adding it though XD

er, wait, this wikidiff2 package is trying to make me install apache and the mediawiki package

this seems undesirable

wha

We also did some relationships at the same time.

You won with respect to the “recorded at” ones.

ah, I wondered if you were doing any of those

yeah, it wants to install mediawiki and php5 (don't have the main php5 metapackage at present)

ianmcorvidae: http://packages.ubuntu.com/uk/precise/php-wikid... says "mediawiki" is recommended...your apt config is probably set to install anything that is recommended as well

hm, right

er, well it does need php5...

I think I had been, but they were silently dropped as already existing at submit time.

how is it running without that? :P

php5 is a metapackage, not the actual implementation

has php5-cli, php5-fpm, etc. already :)

since it's a non-apache setup it's a bit wacky

ah ok

I’m still unsure if I should use a new work for the “Achterbahn” demo, with the different text.

hm

diffs now showing nothing, it appears

oh, I didn't realise the lyrics were different... only listened all the way through once so far

maybe need to pull in the .so

it should check that the extension is installed...

http://wiki.musicbrainz.org/index.php?title=Mus... though :/

I don't see the diff's cache key in the HTML source, weird...

I had a prewarning from the website, in the description of what the deluxe edition contains (“Im vorliegenden Demo hört Ihr noch den ursprünglich gedachten Text.”).

other things seem to use configurations in /etc/php5/conf.d

oh... perhaps I should've read it properly instead of just looking at when it would be released XD

argh, I was looking at the current code, not 1.19. yeah, it'll try to shell out for the diff instead of falling back to PHP

and it's back

loading extensions tends to help :)

:D

https://wiki.musicbrainz.org/index.php?title=Me... http://wiki.musicbrainz.org/MediaWiki:Pagetitle... <-- if you edit those to remove {{SITENAME}} and use "MusicBrainz wiki" instead, it'll save 2 parser invocations on each page load

I should dig up the sysop password so I can edit those, heh

I think I can

apparently I can

since I just did :P

yeah, you're set to bureaucrat/administrator

which presumably I should get myself set to, but :P

that tagline page also, I didn't get that one

whoo

is there a dedicated job runner set up?

(what is $wgJobRunRate set to?)

I think there's no dedicated job runner

yeah, it's set to default

On another wiki I run, we have a cronjob every minute that does: php /path/to/mw/maintenance/runJobs.php --maxjobs 100 --maxtime 55

and $wgJobRunRate=0;

if one minute is too frequent, you could do every 5 or 10 minutes, and just increase maxtime/maxjobs accordingly

just need to make sure whatever user executes that can also write to the filesystem, and any files they create will also be read/writable by the webserver

I'd probably just have www-data run it, unless that's ill-advised for some reason

admittedly adding things to cron is maybe unwise given we already suck at updating it, but :P

www-data should be fine

(right now I have nginx passing anything \.php$ to php-fpm, but it feels like I could be more paranoid about that :P

only the files listed in https://github.com/wikimedia/mediawiki-core/tre...

i.e., only things directly in the git root?

yeah

api, img_auth (you actually don't need this one since it's not a private wiki), index, load, opensearch_desc (I don't even know what this is), profileinfo (don't need this since I'm guessing you don't have profiling turned on), redirect (I think this is gone in modern versions...) thumb, thumb_handler

well, opensearch is for browser "add search engine" things, I see that loaded directly

ah, right

(in /includes/)

make sure your LocalSettings.php/file with passwords in it isn't web accessible :P

yeah, that one's not XD

if you're feeling ambitious we can turn on the file cache

when logged-out users hit the wiki, they'll get the page served from the filesystem instead of pulling it out of the db and rendering it

it kind of acts like a frontend cache

sure, may as well

needs $wgCacheDirectory I guess

yeah

is all of your settings stored in the LocalSettings.php file? or do you include/require other files in it?

all localsettings

ok perfect, MW handles that nicely by default

you don't need $wgCacheDirectory necessarily

by default file cache uses $wgUploadDirectory/cache

ah, I have it using $IP/cache which is nicely forbidden by nginx config

which I think should be good

already see an l10n_cache-en.cdb file

that's localization cache, and also good :D

so it should just be $wgUseFileCache = true; and making sure $wgShowIPinHeader = false;

alright, that's on

it's putting the cache files in the upload directory, which I'm not sure if is a security issue

(rather than $IP/cache, I guess I'd need to set $wgFileCacheDirectory)

it shouldn't be given that it's just wiki content...

yeah, I guess http://wiki.musicbrainz.org/images/cache/8/8e/M... working doesn't really cause issues XD