Différences entre les versions de « MediaWikiFarm static analysis »

De Wiki Seb35
Aller à la navigation Aller à la recherche
(Page créée avec « {| class="wikitable" |- ! rowspan="3" colspan="2" | Time ↧<br /><span style="font-weight:normal;"> <span id="link-mode-monoversion">Monoversion</span> / <span id="link-m... »)
 
(+explanations)
Ligne 1 : Ligne 1 :
([[#Explanations (English)|explanation below]] - [[#Explications (français)|explications ci-dessous)]]
{| class="wikitable"
{| class="wikitable"
|-
|-
Ligne 639 : Ligne 641 :
| style="text-align:center;" | <span class="hide-when-cache-loaded">{{read}}</span><span class="cache-default-hide show-when-cache-loaded void">{{-}}</span>
| style="text-align:center;" | <span class="hide-when-cache-loaded">{{read}}</span><span class="cache-default-hide show-when-cache-loaded void">{{-}}</span>
|}
|}
== Explanations (English) ==
This is a hand-made matrix describing what function read or modify what internal data for the software [https://phabricator.wikimedia.org/diffusion/EMWF/ MediaWikiFarm], a MediaWiki "extension" to manage MediaWiki farms of wikis.
This represents the class [https://phabricator.wikimedia.org/diffusion/EMWF/browse/master/src/MediaWikiFarm.php MediaWikiFarm], which is the main class containing almost all logic. Each row is a method (roughly sorted by chronological order in a typical run) and each column is a class property (all are protected). In each cell, there is either:
* {{read}}: the property is (only) read in the method;
* {{set}}: the property is set in the method (and possibly read);
* {{-}}: the property is neither read or set in the method.
In my previous <s>games</s> works on static analysis, I created [[:mw:File:Call graph of extension MediaWikiFarm.svg|the call graph]] with an external software. But, to be more exact, this call graph is only [[:wikipedia:Call graph|an overapproximation]] since the exact (dynamic) call graph is a subset of this one: in a run, possibly some paths are not executed since it depends on the context.
Here, this is the "data graph", and there are different contexts: on the top left, you can choose the various main contexts in which the software can run. This depends mainly from the environment and the configuration, and the possibilities are only the main ones.
The main result coming from this representation is: "the cache drastically reduces the processing". In fact this is not a surprise, it was designed for it, but such a sparse matrix is encouraging and help to visualise the inter-relations. When benchmarking the software, a no-cache run takes 10-15 milliseconds, and a with-cache run takes 85 microseconds (roughly 130 times less).
== Explications (français) ==

Version du 20 novembre 2016 à 22:36

(explanation below - explications ci-dessous)

Time ↧

Monoversion / Multiversion
No cache / Empty / Loaded
With / Without deployment file
Web / CLI / update
(All) - As of 1b15172

Properties Files
farmDir configDir codeDir cacheDir params farmConfig variables configuration farms.yml variable.yml config.yml versions.yml deployments.php (cache) versions.php (cache) config.php (cache) LocalSettings.php main.php
'EntryPoint' 'ExtensionRegistry' 'variables' 'coreconfig' 'config' Other '$CODE' '$VERSION' Other 'settings' / 'arrays' 'extensions' / 'skins' 'execFiles'
Existence load - - - - - - - - - - - - - - - - - - - - - - - - -
__construct set set set set set set set- read- set set- read- read- set - - - - - - - - read - - -
| ↳ selectFarm - read- - - - - - set- - - - - - - - - read- - - - - - - - -
checkExistence - - - read- - - - read- read- - read read- read- - - - - - - - - set- - - -
| ↳ checkHostVariables - read- read- - - - read- set- - - - set- read- - - - - read- - - - - - - -
| ↳ setVersion - read- read- - read- - - set-- - - set- set- read- - - - - - - read-- read-- - - - -
| ↳ setOtherVariables - - - - - - - - - - - - - - - - - - - - - - - - -
getConfigFile read- - - read- - - - - - - - read- - - - - - - - - - - - - -
setVariable - - - - - - - - - read- - - set- - - - - - - - - - - - -
updateVersionAfterMaintenance - - - - - - - - - - - read - - - - - - - - - - - - -
updateVersion - read-- - - - - - - - - - - read- - - - - - - - set-- - - - -
Configuration loadMediaWikiConfig read- - read- - - read- - - - - - - - read- read- read- - - - - - - - - -
getMediaWikiConfig - - - read- - - - - - - - read- - set- set- set- - - - - - - set- set- -
  ↳ populateSettings - read- - - - - - - read- - - - read- set- set- set- - - read- - - - - - -
  ↳ extractSkinsAndExtensions - - - - - set- - - - - - - - set- set- - - - - - - - - - -
  |  ↳ detectLoadingMechanism - - - - - read- - - - - read- - - - - - - - - - - - - - -
  ↳ createLocalSettings read- - read- - - - - - - - - - - - - - - - - - - - - - -
Utility isLocalSettingsFresh - read - read- - - - - read- - - read- - - - - - - - - - - - - -
replaceVariable - - - - - - - - - - read read read - - - - - - - - - - - -
readFile - - - read - - - - - - - - - - - - - - - - - - - - -
cacheFile - - - read- - - - - - - - - - - - - - - - - - - - - -
(MediaWiki) - - - - - - - - - - - - - - - - - - - - - - - read- read-

Explanations (English)

This is a hand-made matrix describing what function read or modify what internal data for the software MediaWikiFarm, a MediaWiki "extension" to manage MediaWiki farms of wikis.

This represents the class MediaWikiFarm, which is the main class containing almost all logic. Each row is a method (roughly sorted by chronological order in a typical run) and each column is a class property (all are protected). In each cell, there is either:

  • read: the property is (only) read in the method;
  • set: the property is set in the method (and possibly read);
  • -: the property is neither read or set in the method.

In my previous games works on static analysis, I created the call graph with an external software. But, to be more exact, this call graph is only an overapproximation since the exact (dynamic) call graph is a subset of this one: in a run, possibly some paths are not executed since it depends on the context.

Here, this is the "data graph", and there are different contexts: on the top left, you can choose the various main contexts in which the software can run. This depends mainly from the environment and the configuration, and the possibilities are only the main ones.

The main result coming from this representation is: "the cache drastically reduces the processing". In fact this is not a surprise, it was designed for it, but such a sparse matrix is encouraging and help to visualise the inter-relations. When benchmarking the software, a no-cache run takes 10-15 milliseconds, and a with-cache run takes 85 microseconds (roughly 130 times less).

Explications (français)