Page MenuHomePhabricator

Use disk-based LCStore by default in MediaWiki 1.36
Open, MediumPublic

Description

The MediaWiki default is to store localisation cache in the database.

At WMF production, it's been the case for many years that these are stored as a file on disk instead, in a private cache directory. MediaWiki offers two well-tested formats for this: php array files, and CDB files. CDB files is what WMF currently uses in production. PHP-array files is what we're moving toward (T99740), which are even faster to generate (but difficult to manage opcache memory for, T99740).

For third parties, this means:

  • More performant by default. We'd no longer require db-master connections on web requests when repopulating the localisation cache.
  • Better recache performance.
Benchmark
Test case / LCStoreA (database table, current MW default)B (CDB files, current WMF)
(Page load time)2013 ms, 2049 ms, 2049 ms1853 ms, 1907 ms, 1869 ms

This seems like a fairly easy thing to enable by default. Should we do that? Are there reasons we haven't already?

Sub tasks

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Krinkle triaged this task as Medium priority.Apr 23 2019, 5:40 PM
Krinkle added a comment.EditedApr 25 2019, 5:26 PM

Test cases

Three performance costs around writing to / reading from the localisation cache:

  1. Populate LCStore for 1 language. – This is what happens on most third-party wikis, whenever a user first visits the wiki in a given language after a site admin has upgraded MediaWiki and purged the server caches. This represents the amount of time a user page view can be delayed by.

I measure this by running update.php to purge all object caches, truncating the l10n_cache table, and clearing the tmp directory. Then, run php maintenance/rebuildLocalisationCache.php --lang de to populate the cache for one language.


  1. Populate LCStore for all languages. – This is what happens on large-scale wiki farms like WMF, which populate the cache for all languages at once as part of the deployment process.

Measured similar to 1, except running php maintenance/rebuildLocalisationCache.php for all languages (no lang param), and with threads=4.


  1. Measure TTFB from loading the main page . – This measures the time it takes to read localisation messages from LCStore. This is the most important one and represents the cost applied to all page views after the server caches have been populated.

Measured by generating all languages first, then running update.php to purge object caches, and then viewing one page. In between page views, running update.php again to purge object caches.

This because LCStore has another layer of caching on top from MessageCache, which uses db-objectcache as "clusterCache" by default. The MessageCache also has optional WANObjectCache (disabled by default) and llocalServerCache (APC) also disabled by default (wgUseLocalMessageCache).


Environment

From addshore/mediawiki-docker-dev (master at f12a8f9). Using PHP setting RUNTIMEVERSION=7.2, on Docker for Mac, with 4 CPU cores given to Docker – verified on the guest via python; import multiprocessing multiprocessing.cpu_count().

Test A - LCStore as database table (current MW stock default)
# This let's MediaWiki core decide,
# The stock default it picks is to use a "l10n_cache" database table.
# -------

# Database (from mdd/LocalSettings)
// [mysql database settings]

# Database (from core/DevelopmentSettings)
$wgSQLMode = 'TRADITIONAL'; // strict mode

# Disk (from mdd/LocalSettings)
$wgTmpDirectory = "{$wgUploadDirectory}/tmp";

# Language (from mdd/LocalSettings)
$wgLanguageCode = "en";

# Extensions (from my own LocalSettings)
wfLoadSkin('Vector');
wfLoadExtension('Cite');
wfLoadExtension('Gadgets');
wfLoadExtension('Interwiki');
wfLoadExtension('ParserFunctions');
wfLoadExtension('WikiEditor');
wfLoadExtension('CategoryTree');
Test B - LCStore as CDB on disk (current WMF use)
# Change $wgCacheDirectory from the default false to a writable tmp directory.
# With this in place, MediaWiki automatically starts using a disk-based LCStore
# instead of in the database. The file format it currently picks is CDB.

$wgCacheDirectory = $wgTmpDirectory;

# … rest same as Test A
Test C - LCStore as static array on disk (proposed)
$wgCacheDirectory = $wgTmpDirectory;
$wgLocalisationCacheConf['store'] = 'array';

# … rest same as Test A

Results

Raw results
## Results A1 (database table / one language)

Rebuilding de... 1 languages rebuilt out of 1
real	0m3.782s
user	0m0.560s
sys	0m0.310s

Rebuilding de... 1 languages rebuilt out of 1
real	0m4.000s
user	0m0.630s
sys	0m0.330s

Rebuilding de... 1 languages rebuilt out of 1
real	0m3.981s
user	0m0.510s
sys	0m0.450s

## Results A2 (database table / all languages)

Rebuilding...
real	1m51.781s
user	1m34.650s
sys	1m0.540s

Rebuilding...
real	1m47.267s
user	1m32.090s
sys	0m57.790s

Rebuilding...
real	1m33.337s
user	0m44.470s
sys	0m26.440s

## Results A3 (database table / page load)

responseStart: 2013.925 ms
responseStart: 2049.880 ms
responseStart: 2049.881 ms

## Results B1 (CDB files / one language)

Rebuilding de... 1 languages rebuilt out of 1
real	0m4.630s
user	0m1.310s
sys	0m0.720s

Rebuilding de... 1 languages rebuilt out of 1
real	0m4.635s
user	0m1.280s
sys	0m0.800s

Rebuilding de... 1 languages rebuilt out of 1
real	0m4.391s
user	0m1.140s
sys	0m0.800s

##  Results B2 (CDB files / all languages)

Rebuilding..
real	4m10.834s
user	8m35.780s
sys	5m52.070s

Rebuilding..
real	4m20.847s
user	9m4.440s
sys	6m3.750s

Rebuilding...
real	4m16.865s
user	8m50.060s
sys	5m56.830s

## Results B3 (CDB files / page load)

responseStart: 1853.005 ms
responseStart: 1907.499 ms
responseStart: 1869.214 ms

## Results C1 (static array files / one language)

Rebuilding de... 1 languages rebuilt out of 1
real	0m3.118s
user	0m0.400s
sys	0m0.220s

Rebuilding de... 1 languages rebuilt out of 1
real	0m3.161s
user	0m0.320s
sys	0m0.290s

Rebuilding de... 1 languages rebuilt out of 1
real	0m3.041s
user	0m0.350s
sys	0m0.280s

## Results C2 (static array files / all languages)

Rebuilding...
real	1m13.084s
user	1m35.640s
sys	1m17.810s

Rebuilding...
real	1m13.043s
user	1m37.700s
sys	1m14.950s

Rebuilding...
real	1m10.789s
user	1m35.650s
sys	1m11.540s

## Results C3 (static array files / page load)

responseStart: 1771.395 ms
responseStart: 1628.985 ms
responseStart: 1809.974 ms
Test case / LCStoreA (database table, current MW default)B (CDB files, current WMF)C (static array files, proposed)
1 (Populate 1 language)3.782s, 4.000s, 3.981s4.630s, 4.635s, 4.391s 3.118s, 3.161s, 3.041s
2 (Populate all languages)1m51s, 1m47s, 1m33s4m10s, 4m20s, 4m16s 1m13s, 1m13s, 1m10s
3 (Page load time)2013 ms, 2049 ms, 2049 ms1853 ms, 1907 ms, 1869 ms 1771 ms, 1628 ms, 1809 ms

The most important one for end-users is the page load time as that cost may be paid by users on any page view, as opposed to only when upgrading the site. Both of the disk-based caches came out better than the database table, thus confirming out hypothesis.

Among the two file formats for on-disk caching, the the static array file format came out better than the CDB file format. This matches our expectation and tests we ran in 2015 in WMF production when we first started the migration from CDB files to PHP files (T212460, T99740). We've completed most of that migration in WMF production. The only remaining disk-based caching we have that isn't yet using static arrays instead of CDB is the localisation cache.

The comparison between CDB and static arrays for populating the caches (for site admins during upgrades and deployments) also came out as expected and matching our 2015 tests, favouring the static array format.

The surprising bit to me, although not particularly important for this task, is that the CDB files were much slower to fill than the database tables (4 minutes vs 1 minute). This is a good reason to stick with our proposal to switch from database tables toward static array files, and never use CDB files by default for third parties.

At WMF the cost of slowly generating CDB files (over db tables) was justified many years ago because our focus is on the end user and the page load performance. We're happy to pay a few minutes during deployment so as to not require database load for localisation messages. Having said that, once we switch from CDB to static array files at WMF as well, it'll be nice to know our deployment process will likely be much faster. The ticket for that is T99740.

Krinkle added a comment.EditedApr 25 2019, 5:42 PM

Next step here is deciding what $wgCacheDirectory should default to. Note that in order to uphold our current guarantees to third parties, this directory must vary by wiki or be within the installation path.

It must vary by wiki, because there can be multiple wikis on the same server that each have similar but incompatible extension installed. At WMF, we explicitly don't support this and thus share our cache directory between wikis as optimisation (thus sharing computed cache files much better), but we can't do that for MW default. This isn't a big deal, because we're going from no caching to some caching, so it's an improvement either way.

There's a few candidates we can pick from:

  • $wgTmpDirectory – we can rely on this to be a writable path, used for lots of ad-hoc purposes currently. We should carve out a sub directory under this, because it is set to a system-wide directory by default. E.g. $tmpDir/mw-cache.
  • $wgUploadDirectory - we can rely on this to be a writable path, already used for HTML-FileCache ($wgFileCacheDirectory) and for $wgReadOnlyFile. Adding wgCacheDirectory to that, seems straight forward and should naturally deal with the by-version/by-wiki variance. On wiki farms, site admins already have this set to vary accordingly.

Concerns, preferences, other ideas?

aaron added a comment.Apr 26 2019, 7:44 PM

Did you try sqlite LCStore (with journal_mode = WAL and synchronous = NORMAL? like the installer uses)?

Did the CDB test use the PHP CDB implementation or the implementation using dba_* functions?

Krinkle added a comment.EditedMay 4 2019, 5:50 PM

Did the CDB test use the PHP CDB implementation or the implementation using dba_* functions?

Aye, this was with php72 as provided by the php:7.2 image on DockerHub, used via webdevops' php-nginx image, via MDD: mediawiki-docker-dev. And that installs php without --with-cdb or --with-dba=shared. I've confirmed via mwscript eval.php that Cdb\Writer::open( '/tmp/foo.cdb' ); on this installation results in a Cdb\Writer\PHP instance.

I'm curious whether it's generally common for third-parties to lack this as well.

  • Debian 9 Stretch: php 7.0, without dba functions.
  • Debian 10 Buster: php 7.3, without dba functions.
  • Ubuntu 16.04 Xenial, php 7.0, without dba functions.
  • Ubuntu 18.04 Bionic, php 7.2, without dba functions.
Log
$ docker run --rm -i -t debian:stretch sh -c "bash"
# apt-get update …
# apt-get install php … php7.0 (7.0.33-0+deb9u3)
php -a
> var_dump(dba_handlers());
Uncaught Error: Call to undefined function dba_handlers()

$ docker run --rm -i -t debian:buster sh -c "bash"
# apt-get update …
# apt-get install php … php7.3 (7.3.4-2)
# php -a
> var_dump(dba_handlers());
Uncaught Error: Call to undefined function dba_handlers()

$ docker run --rm -i -t ubuntu:16.04 sh -c "bash"
# apt-get update …
# apt-get install php … php7.0 (7.0.33-0ubuntu0.16.04.3)
# php -a
php > var_dump(dba_handlers());
Uncaught Error: Call to undefined function dba_handlers()

$ docker run --rm -i -t ubuntu:18.04 sh -c "bash"
# apt-get update …
# apt-get install php … php7.2 (7.2.17-0ubuntu0.18.04.1)
# php -a
php > var_dump(dba_handlers());
Uncaught Error: Call to undefined function dba_handlers()

Did the CDB test use the PHP CDB implementation or the implementation using dba_* functions?

These are not installed by default on popular distros per T218207#5157534. However, the native is indeed known to be faster.

In the unlikely event that Cdb-Dba (as opposed to Cdb-Php) is also faster than StaticArray, I still do not think we default to "Cdb" over "StaticArray" as that would mean for most wikis it would be slow by default. If an administrator is customising their environment by installing php7.2-dba and wants to use Cdb for MW, they can still set $wgLocalisationCacheConf['store'] = 'cdb';. Which is actually what those administrators would already be doing today. We're only changing the default. We are not removing support for anything.

Anyhow, here's a comparison, same methods and environment as per T218207#5138303. I'm re-testing Cdb-Php and StaticArray here to give it a fresh baseline, because absolute numbers may no longer compare.

Cdb-Php
Test: Page load time
responseStart: 2762 ms, 3298 ms, 3004 ms
Test: Deploy one language
real	0m4.832s, 0m4.939s, 0m4.881s

The Dba functions were installed by using docker-php-ext-install dba. Confirmed by dba_handlers() from eval.

Cdb-Dba
Test: Page load time
responseStart: 2504 ms, 3078 ms, 3149 ms
Test: Deploy one language
real	0m3.298s, 0m3.225s, 0m3.015s
StaticArray
Test: Page load time
responseStart: 2546 ms, 2728 ms, 2753 ms
Test: Deploy one language
real	0m3.322s, 0m3.224s, 0m3.055s

Cdb-Dba is faster than Cdb-Php both for writing and for reading cache values, as expected.

Compared to StaticArray, Cdb-Dba is on-par on both accounts. Cdb-Dba has more outliers for user-perceived metrics, and StaticArray has one outlier for the deploy runtime. Both both had the same range of values. And in any case, we cannot assume Dba to be installed, so StaticArray remains the better choice as our default. It also helps generally, I think, whenever we can use the WMF production setting as MW default, as third-parties then benefit all optimisations and resources dedicated to its maintenance and performance.

Did you try sqlite LCStore (with journal_mode = WAL and synchronous = NORMAL? like the installer uses)?

Interesting. In the specific case of SQLite, "cache in database" and "cache on disk" are effectively both use the disk. Some quick comparisons using Quick MediaWiki to install MediaWiki with SQLite (macOS, on-disk /private/tmp/quickmw, PHP 7.1.26 from Homebrew).

SQLite (default installation)
LocalSettings.php (generated)
$wgLocalisationCacheConf['storeServer'] = [
	'type' => 'sqlite',
	'dbname' => "{$wgDBname}_l10n_cache",
	'tablePrefix' => '',
	'variables' => [ 'synchronous' => 'NORMAL' ],
	'dbDirectory' => $wgSQLiteDataDir,
	'trxMode' => 'IMMEDIATE',
	'flags' => 0
];
Test: Deploy one language
time php maintenance/rebuildLocalisationCache.php --lang de --force
real	0m0.404s, 0m0.416s, 0m0.407s
StaticArray
LocalSettings.php (appendix)
$wgCacheDirectory = $wgSQLiteDataDir;
$wgLocalisationCacheConf['store'] = 'array';
Test: Deploy one language
real	0m0.140s, 0m0.156s, 0m0.148s

Looks like Static Array beats SQLite as well. We've shown in all previous benchmarks that the "All languages" and "Page load time" use cases always align with the "One language" use case, so I won't bother re-running those. Besides, I don't think this would inform our decision here, as I don't think we should optimise the stock MW default for SQLite against MySQL and other RDBMS'es.

In the unlikely event someone finds that sqlite3-based writing or reading outperforms opcache-backed arrays, it will still work by default, and can be optimised by setting wgLocalisationCacheConf directly.

Next step here is deciding what $wgCacheDirectory should default to. [..] There's a few candidates we can pick from:

  • $wgTmpDirectory – we can rely on this to be a writable path, used for [..]
  • $wgUploadDirectory - we can rely on this to be a writable path, already used for [..]

Concerns, preferences, other ideas?

Storing executable files in $wgUploadDirectory which is usually web-accessible sounds scary to me. Sub-directory of $wgTmpDirectory sounds a better option to me. One small thing might be that perhaps $wgUploadDirectory might play better with selinux if it is inside mediawiki installation directory, unlike $wgTmpDirectory. More generally, the concept of "executable code generated during runtime" is now being introduced (or did I miss a precedence?) and probably could benefit from documentation to help people who try to secure MediaWiki deployments or for people doing MediaWiki deployment systems in general.

Krinkle added a comment.EditedMay 6 2019, 4:48 PM

Storing executable files in $wgUploadDirectory which is usually web-accessible sounds scary to me.

1: Re-use wgUploadDirectory

Aye. There would have to been been several security compromises for that to be a risk, though. One would need to have explicitly disabled wgHashedUploadDirectory (it is enabled by default), and to have whitelisted .php, and to have broken MediaWiki so that allows uploads containing PHP code - and – allow slashes in user images - and - allow image names to start with a lowercase letter. So that a file upload can then be written to uploads/mw-cache/l10n-en.php instead of uploads/a/a0/Filename.png.

As such, it seems wgUploadDirectory is safe to use for this by default.

And if we do, we could consider doing T199590 as well. The only way to compromise it then, is if someone has access to the server to write anywhere that PHP could write to, in which nothing we pick is safe.

2: Re-use wgTmpDirectory

The downside of wgTmpDirectory is resource management. We would need to (by default) make sure we have a 1-to-1 mapping between MW installs and tmp sub directories.

This is because caches can vary by which extensions are installed, and configuration etc. So we can't just use /tmp or even /tmp-cache-{mw_version}. It would need to be something like /tmp/mw-cache-{wiki_id}-{mw_version}-{hash of $InstallPath}. The downside then, is that they would always stay behind and consume disk space after upgrades.

It also means that while nothing is broken by default, it would be quite inefficient for multi-wiki set ups that share the same code base for multiple wikis. Each wiki would have its own cache directory by default. Whereas today our default for when multiple wikis share the same code, is to assume cache should be shared and site admins have to specifically opt-out if they don't want that (by setting the configuration accordingly, like they would already do for various other configs).

All our use of /tmp so far has always been self-cleaning. This would somewhat depart from that.

3: Re-use $IP/cache

Another option is to use :mw/cache/. So no re-use of /tmp or :mw/uploads/. The benefit would be that there is no conflict with uploads, and that site admins can easily disable access for all of /cache (which we can do by default with .htaccess for Apache, like we do elsewhere already). This directory is already being used in MW by default for storing SQLite databases. The downside is that it would require more documentation and awareness for site admins using MySQL etc. (Because so far they've been able to ignore our advice to disable web-access to IP/cache.)

This isn't unprecedented, however. We do this already for HTML-FileCache, and for private/deleted uploads - which are also stored in such a directory and are also web-accessible by default if the site admin doesn't configure them properly.

On the other hand, if it requires awareness of the site administrator manually do something, it might also make sense to have it be an advertised and well-documented opt-in that is technically disabled by default. E.g. the technical default would be /tmp but we would in the installer check if /cache is web-accessible and if not, warn against that, and if it has been disabled already (as it should be) generate LocalSettings to use it. This is a compromise of both. Thoughts?

Paladox added a subscriber: Paladox.May 6 2019, 4:52 PM

Change 508422 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] localisation: Improve documentation around wgLocalisationCacheConf

https://gerrit.wikimedia.org/r/508422

Change 508423 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] localisation: Inject 'directory' option to LCStore classes

https://gerrit.wikimedia.org/r/508423

Change 508422 merged by jenkins-bot:
[mediawiki/core@master] localisation: Improve documentation around wgLocalisationCacheConf

https://gerrit.wikimedia.org/r/508422

Change 508423 merged by jenkins-bot:
[mediawiki/core@master] localisation: Inject 'directory' option to LCStore classes

https://gerrit.wikimedia.org/r/508423

Change 528907 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] DefaultSettings: Document wgTmpDirectory guarantees and expectations

https://gerrit.wikimedia.org/r/528907

I think as the first step we can add it to DevelopmentSettings.php. For one reason is that we put experimental configs there first and then slowly we migrate to to DefaultSettings.php (I admit the reason I care is that our tests are extremely slow because of more than 50k db queries to l10n_cache in every quibble run)

Change 529057 had a related patch set uploaded (by Ladsgroup; owner: Ladsgroup):
[mediawiki/core@master] Set l10n cache to array in DevelopmentSettings.php

https://gerrit.wikimedia.org/r/529057

Change 528907 merged by jenkins-bot:
[mediawiki/core@master] DefaultSettings: Document wgTmpDirectory guarantees and expectations

https://gerrit.wikimedia.org/r/528907

Change 532730 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] MessageCache: Minor wgMsgCacheExpiry doc fix, and cleare constant access

https://gerrit.wikimedia.org/r/532730

Change 532732 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] MessageCache: Increase APC 'messages-big' expiry from 1min to 1h

https://gerrit.wikimedia.org/r/532732

Change 532730 merged by jenkins-bot:
[mediawiki/core@master] MessageCache: Minor wgMsgCacheExpiry doc fix, and clear constant access

https://gerrit.wikimedia.org/r/532730

Change 532732 merged by jenkins-bot:
[mediawiki/core@master] MessageCache: Increase APC 'messages-big' expiry from 1min to 1h

https://gerrit.wikimedia.org/r/532732

I was testing this and noticed one significant issue when running rebuildLocalisationCache.php:

  • With files (aka CDB) memory use stays <100M for each thread when running with 4 threads.
  • With array memory use grows >500M for each thread when running with 4 threads.

PHP 7.1.31. in case it is relevant.

I was testing this and noticed one significant issue when running rebuildLocalisationCache.php:

  • With files (aka CDB) memory use stays <100M for each thread when running with 4 threads.
  • With array memory use grows >500M for each thread when running with 4 threads.

PHP 7.1.31. in case it is relevant.

What are $wgMemoryLimit and PHP memory_limit set to?

Did you see it grow the whole time and 500M is where it ended, or does it get to 500M early on and then remain stable at that level? I'll be sure to test for this as well before making any changes.

Command line scripts do not have any memory limit unless specified separately.

It grew during the duration of the script, reaching 500M at the end, while the files <100M stayed relatively stable.

Change 534527 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] localisation: Release data from memory in LCStoreStaticArray::finishWrite

https://gerrit.wikimedia.org/r/534527

Krinkle added a comment.EditedSep 4 2019, 8:45 PM

Thanks @Nikerabbit I'm able to reproduce the leak, as well as confirm that CDB wasn't affected. I found the source of the leak and fixed it in the above patch.

Change 534527 merged by jenkins-bot:
[mediawiki/core@master] localisation: Release data from memory in LCStoreStaticArray::finishWrite

https://gerrit.wikimedia.org/r/534527

Hey there, should this be moved to 1.35? The cut is a couple of weeks away. If it needs to go out in 1.34, is there anything I can do to help get it out of the door?

The next step here is deciding on what wgCacheDirectory would be by default. Some options and thoughts from me about that are at T218207#5160934. I'm basically just waiting for others to say whether some or all of those are a bad idea.

WDoranWMF raised the priority of this task from Medium to High.EditedSep 6 2019, 5:54 PM
WDoranWMF moved this task from Inbox to Feature Requests to Review on the Platform Engineering board.
WDoranWMF added a subscriber: WDoranWMF.

I'm moving the priority up a little for the PMs to make a decision, it can be moved back down once they've confirmed.

aaron added a comment.Sep 10 2019, 2:53 AM

Interesting. In the specific case of SQLite, "cache in database" and "cache on disk" are effectively both use the disk. Some quick comparisons using Quick MediaWiki to install MediaWiki with SQLite (macOS, on-disk /private/tmp/quickmw, PHP 7.1.26 from Homebrew).

SQLite (default installation)
LocalSettings.php (generated)
$wgLocalisationCacheConf['storeServer'] = [
	'type' => 'sqlite',
	'dbname' => "{$wgDBname}_l10n_cache",
	'tablePrefix' => '',
	'variables' => [ 'synchronous' => 'NORMAL' ],
	'dbDirectory' => $wgSQLiteDataDir,
	'trxMode' => 'IMMEDIATE',
	'flags' => 0
];
Test: Deploy one language
time php maintenance/rebuildLocalisationCache.php --lang de --force
real	0m0.404s, 0m0.416s, 0m0.407s
StaticArray
LocalSettings.php (appendix)
$wgCacheDirectory = $wgSQLiteDataDir;
$wgLocalisationCacheConf['store'] = 'array';
Test: Deploy one language
real	0m0.140s, 0m0.156s, 0m0.148s

Looks like Static Array beats SQLite as well. We've shown in all previous benchmarks that the "All languages" and "Page load time" use cases always align with the "One language" use case, so I won't bother re-running those. Besides, I don't think this would inform our decision here, as I don't think we should optimise the stock MW default for SQLite against MySQL and other RDBMS'es.

In the unlikely event someone finds that sqlite3-based writing or reading outperforms opcache-backed arrays, it will still work by default, and can be optimised by setting wgLocalisationCacheConf directly.

FYI, with https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/535338 and SQLite 3.30 (compiled), I get:

# SQLite (cold table)
aaron@DESKTOP-78G5GQL:~/OSS/core$ sudo -u www-data echo "delete from l10n_cache" | sqlite3 /home/data/my_wiki_l10n_cache.sqlite
aaron@DESKTOP-78G5GQL:~/OSS/core$ sudo -u www-data php maintenance/rebuildLocalisationCache.php --lang de --force
Rebuilding de...done (205ms)

# SQLite (table already set)
aaron@DESKTOP-78G5GQL:~/OSS/core$ sudo -u www-data php maintenance/rebuildLocalisationCache.php --lang de --force
Rebuilding de...done (122ms)
1 languages rebuilt out of 1

# LCStoreStaticArray
aaron@DESKTOP-78G5GQL:~/OSS/core$ sudo -u www-data php maintenance/rebuildLocalisationCache.php --lang de --force
Rebuilding de...done (106ms)
1 languages rebuilt out of 1

It's hard to beat file_put_contents().

We're discussing this in CPT feature request meeting, and we think it should be decided before 1.35 but shouldn't gate the 1.34 release per @Jdforrester-WMF

Change 529057 merged by jenkins-bot:
[mediawiki/core@master] Set l18n cache to array in DevelopmentSettings.php

https://gerrit.wikimedia.org/r/529057

Krinkle renamed this task from Use disk-based LCStore by default in MediaWiki 1.34 to Use disk-based LCStore by default in MediaWiki 1.35.Oct 5 2019, 2:35 AM

Updating title to reflect priority from CPT (thirty-party wikis will remain on the slower SQL-based LCStore for MW 1.34).

Krinkle updated the task description. (Show Details)Oct 5 2019, 2:40 AM

Moving back as we're now half-way the 1.35 cycle. This is blocked on deciding if and what to use as the default cache directory in MediaWiki core. See previous comments for arguments in favour and against various of the options I was able to gather.

eprodromou added a subscriber: CCicalese_WMF.

CPT needs to provide input on a technical decision. We (@CCicalese_WMF and I) think this would be good for a technical planning discussion, so we're adding to Clinic Duty and tagging for @WDoranWMF .

Speaking as a disinterested person, $IP/cache seems the most sensible option to me.

daniel lowered the priority of this task from High to Medium.Apr 7 2020, 12:53 PM

Change 594218 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] language: Add test coverage for LCStoreStaticArray

https://gerrit.wikimedia.org/r/594218

Change 594234 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] language: Avoid LCStoreStaticArray::decode() recursion for arrays

https://gerrit.wikimedia.org/r/594234

Change 594218 merged by jenkins-bot:
[mediawiki/core@master] language: Add test coverage for LCStoreStaticArray

https://gerrit.wikimedia.org/r/594218

Change 594234 merged by jenkins-bot:
[mediawiki/core@master] language: Avoid LCStoreStaticArray::decode() recursion for arrays

https://gerrit.wikimedia.org/r/594234

Moving on workboard from Backlog to Next, since the Backlog column was hidden some time ago. Was T218207#5866709 ever resolved?

Krinkle added a comment.EditedMay 22 2020, 4:57 PM

Not yet. This is still pending advice/direction from CPT to decide where we want to store this in MW by default, based on the options and trade-offs provided above.

Krinkle updated the task description. (Show Details)May 26 2020, 6:34 PM
Legoktm added a subscriber: Legoktm.

Bumping again, doesn't seem like enough progress has been made yet.

Jdforrester-WMF renamed this task from Use disk-based LCStore by default in MediaWiki 1.35 to Use disk-based LCStore by default in MediaWiki 1.36.Jul 29 2020, 9:03 AM