Hi,
I cannot actually answer this question (it is not easy), but I
sometimes get this kind of question related to our main relational
database storage (MariaDB). I am preparing some slides for a
presentation, and took some numbers and wanted to share those with you
(as of June 2019):
* There is approximately 550 TB of used data in the MariaDB-related
servers along the Wikimedia infrastructure (mostly compressed in some
way- InnoDB, gzip, etc.)
* If we do not account for redundancy, 60TB of data is unique (average
of 9x redundancy, which seems about right)
** Of that, 24TB is for insert-only highly-compressed content (External Storage)
** The rest is metadata, local content, misc services, disc cache,
analytics, cloud dbs, and backups.
Please note this doesn't have into account storage in other mediums or
technologies (search, maps, analytics, REST, file storage, etc.). Also
content compression be very efficient so uncompressed data can be much
larger. We are in fact aiming at reducing even more the storage
footprint over the next months.
If someone is interested on seeing size evolution, you can get the
latest up to date metrics on Grafana:
https://grafana.wikimedia.org/d/000000607/cluster-overview?orgId=1&var-data…
--
Jaime Crespo
<http://wikimedia.org>
Hey all,
A quick heads-up: the continuous integration tests for MediaWiki core,
MediaWiki extensions, and MediaWiki skins are now all using node 10,
replacing node 6, which is end-of-life.
CI jobs were replaced by new ones which should run faster, without any
disruption for developers' work. For a brief period, selenium tests were
disabled; they've now been re-enabled for all repos.[0]
There are still a number of repos running node6 CI, which will need work to
convert over in future.[1]
This work also unblocks a number of issues, including:
* committing package-lock, making for faster and more secure development[2],
* using the newest version of stylelint (e.g. [3]), and
* upgrading browser tests to webdriverio 5+ [4].
Antoine and I think we've checked for issues, but if you run into any,
please report them on Phabricator.[0]
[0] – https://phabricator.wikimedia.org/T222406
[1] – https://phabricator.wikimedia.org/T211784
[2] – https://phabricator.wikimedia.org/T179229
[3] – https://gerrit.wikimedia.org/r/c/510822
[4] – https://phabricator.wikimedia.org/T213268
J.
--
*James D. Forrester* (he/him <http://pronoun.is/he> or they/themself
<http://pronoun.is/they/.../themself>)
Wikimedia Foundation <https://wikimediafoundation.org/>
Could this change [1] be backported to VE release branches (REL1_32,
REL1_31, etc)? Without it initializing submodules fails due to the gerrit
path change. This may affect other extensions/projects as well, but this VE
error has been reported to me by several people. Until recently it had only
happened within within specific cloud hosting environments, but now I just
got the failure within Travis CI [2] which worked fine yesterday.
[1]
https://github.com/wikimedia/mediawiki-extensions-VisualEditor/commit/6f6d8…
[2]
https://travis-ci.org/enterprisemediawiki/meza/jobs/540726316#L2646-L2652
Thanks,
James
Hey all,
The idea of separating PHPUnit unit and integration/system tests in MediaWiki core has been around for some time[1][2][3]. Currently, the tests assume the presence of valid MediaWiki settings and a database connection, meaning one must install & configure MediaWiki and an RDBMS in their local development environment to be able to run the tests. The fact we use a non-standard entry point (phpunit.php) also makes these tests incompatible with existing tooling such as IDE integrations.[4]
At the 2019 hackathon I worked with Amir Sarabadani, Michael Große and Kosta Harlan to perform some preliminary investigation into separating unit tests (that can be run without a database and MediaWiki configuration) into a separate PHPUnit configuration that could be run via the official phpunit binary. After some additional work, this has evolved into a patch that separates 5301 unit tests into a dedicated suite that can be executed via vendor/bin/phpunit in 15 seconds (on my machine!). By contrast, running the same 5301 tests via phpunit.php takes around 30 seconds.[5] Not using phpunit.php here also allows for integrating with e.g. Intellij/PHPStorm’s test execution and code coverage functionality—here’s a screenshot of the execution and coverage information of PathRouterTest via IntelliJ.[6] I feel that these benefits would be felt both by developers and CI maintainers—developers could iterate more rapidly by running the unit tests, and Jenkins would have to spend less time executing the test suite.
I’d like to thank everyone who has supported this enterprise so far—Amir (Ladsgroup) for creating a script to identify the initial set of tests that do not rely on a database[7][8] and providing assistance throughout, Kosta Harlan for highlighting this old and forgotten issue and bringing it to the hackathon, Bartosz Dziewoński (MatmaRex) for providing a solution to scoping issues around MediaWiki core files,[9] Michael Große for demonstrating the feasibility of this approach in the Wikibase extension test suite,[10] and James Forrester for reviewing the changes and outlining possible next steps.
However, the work is far from done yet! The patch is not yet merged, so any reviews, comments and suggestions would be very welcome there! And if it does get merged, we will have to think about how to bring this separation to extensions’ test suites as well as potentially port more core tests to the unit test suite. So if you have any ideas on how to improve this patch or would like to add to the next steps, don’t hesitate to leave a note :)
[1] https://phabricator.wikimedia.org/T89432
[2] https://phabricator.wikimedia.org/T87781
[3] https://phabricator.wikimedia.org/T84948
[4] https://www.mediawiki.org/wiki/Manual:PHP_unit_testing/Running_the_unit_tes…
[5] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/513106
[6] https://phabricator.wikimedia.org/F29316124
[7] https://phabricator.wikimedia.org/T87781#5194643
[8] https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/510226/
[9] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/513106#message-32b2a171a7…
[10] https://gerrit.wikimedia.org/r/511035
Yours,
---
Máté Szabó
Software Engineer
+36 30 947 5903
WIKIA sp. z o.o. z siedzibą w Poznaniu, ul. Abp. A. Baraniaka 6
Sąd Rejonowy Poznań – Nowe Miasto i Wilda w Poznaniu, VIII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 0000254365
NIP: 5252358778
Kapitał zakładowy: 50.000,00 złotych