Change Details

The XHGui profiling tool currently stores its data in an old version of MongoDB. Due to licensing changes, it is no longer feasible for us to use MongoDB. Per T180761, I've updated XHGui to use MariaDB instead, but we need somewhere to host this database. It needs to be reachable from MediaWiki (possibly just the mwdebugXXXX hosts?) as well as the host serving the XHGui front-end (webperf1002). Data will be written to this database only when `profile` is present in the `X-Mediawiki-Debug` header (i.e. only when requested by someone debugging a problem), one row per request. Row size varies based on the page being profiled. It does not need to be retained very long - perhaps a few weeks at most? Likewise, we probably do not need to back it up. Cross-DC replication would be nice to have, but is not a hard requirement. In a cross-DC scenario, MediaWiki would write to the master instance, MariaDB would be responsible for replicating those writes, and each XHGui front-end would read from the database in its local datacenter. I think this probably belongs in one of the "misc" shards, similar to other tools such as Etherpad or Phabricator.

The XHGui profiling tool currently stores its data in an old version of MongoDB. Due to licensing changes, it is no longer feasible for us to use MongoDB. Per T180761, I've updated XHGui to use MariaDB instead, but we need somewhere to host this database. It needs to be reachable from MediaWiki (possibly just the mwdebugXXXX hosts?) as well as the host serving the XHGui front-end (webperf1002). Data will be written to this database only when `profile` is present in the `X-Wikimedia-Debug` header (i.e. only when requested by someone debugging a problem), one row per request. Row size varies based on the page being profiled. It does not need to be retained very long - perhaps a few weeks at most? Likewise, we probably do not need to back it up. Cross-DC replication would be nice to have, but is not a hard requirement. In a cross-DC scenario, MediaWiki would write to the master instance, MariaDB would be responsible for replicating those writes, and each XHGui front-end would read from the database in its local datacenter. I think this probably belongs in one of the "misc" shards, similar to other tools such as Etherpad or Phabricator.

The XHGui profiling tool currently stores its data in an old version of MongoDB. Due to licensing changes, it is no longer feasible for us to use MongoDB. Per T180761, I've updated XHGui to use MariaDB instead, but we need somewhere to host this database. It needs to be reachable from MediaWiki (possibly just the mwdebugXXXX hosts?) as well as the host serving the XHGui front-end (webperf1002). Data will be written to this database only when `profile` is present in the `X-Mediawiki`X-Wikimedia-Debug` header (i.e. only when requested by someone debugging a problem), one row per request. Row size varies based on the page being profiled. It does not need to be retained very long - perhaps a few weeks at most? Likewise, we probably do not need to back it up. Cross-DC replication would be nice to have, but is not a hard requirement. In a cross-DC scenario, MediaWiki would write to the master instance, MariaDB would be responsible for replicating those writes, and each XHGui front-end would read from the database in its local datacenter. I think this probably belongs in one of the "misc" shards, similar to other tools such as Etherpad or Phabricator.