Page MenuHomePhabricator

[INVESTIGATION 16hrs] Speed improvements for saving statements and creating new items
Closed, ResolvedPublic

Description

Currently the speed of saving a statement on an entity as well as displaying a new item page after clicking Create on Special:NewItem falls short of speed targets that were defined in T299504. The target speed for both is <1000.

We need to investigate the root cause of the slowness and identify options for improving performance that can be estimated by the engineering team.

Dev note:

  • When we looked at T298027#7625308 we saw a ~2x speed improvement by increasing resource allocation of pods (e.g. more memory and cpu). There is no need to repeat the investigation of impact of adjusting resources

Team agreed on timeboxing the investigation to 16 personhours.

Useful link

Event Timeline

Per At launch, we are at least as performant as WBstack.com, not worse (“speed” of user interactions, not average uptime) from https://docs.google.com/document/d/17cu6WJKHBcpFliCZ0nUE65S0SAtXqx-Gp8145ELZl0c/edit I do not believe that this task or the parent task should block migration launch / be in the Launch backlog column as we have been using it in the past day or 2.

WMDE-leszek renamed this task from [INVESTIGATION] Speed improvements for saving statements and creating new items to [INVESTIGATION 16hrs] Speed improvements for saving statements and creating new items.Apr 6 2022, 10:28 AM
WMDE-leszek updated the task description. (Show Details)
toan updated the task description. (Show Details)

I had a wee look at how we can install the dependencies for this yesterday and with some pull-requests to maybe consider.

Install deps conditionally
https://github.com/wbstack/mediawiki/pull/252

Make building the image less painful
https://github.com/wbstack/mediawiki/pull/253

And for use with skaffold
https://github.com/wmde/wbaas-deploy/pull/290

Also found this that looked interesting https://redis.io/docs/reference/optimization/benchmarks/, should probably be around in our installation too.

I had a closer look at the traces produced by xdebug and turns out most of the time is spent preventing spam

If you disable StopForumSpam we can create items at around 2 secs

Some talky talk from mattermost

Right, im starting to see some things that may link together.
SFS (StopForumSpam) makes uses of the MediaWiki cache, to store some bad IP addresses, if it is not cached, it will fetch (curl) from a remote URL.
3:34 PM

The cache it will use right now is redis, as that is the main cache for MW, (so redis isn't only sessions).
As that is designed for minimal caching right now the SFS data probably leaves the cache quite often resulting in new fetches
Tobias Andersson
3:34 PM

that sounds awesome
Adam Shorland
3:35 PM

so thats probably 1 thing to look at (I didnt test this hypothosis yet)
3:35 PM

now about to look at addCidr specifically
3:37 PM

I dont see addCidr in SFS extension at all
3:38 PM

but addCidr is used in IPSet which is used in the DenyListManager
3:39 PM

So the 11 seconds is in https://github.com/wikimedia/mediawiki-extensions-StopForumSpam/blob/950d636ebde9f7846648967aade0ee8db6a80ab0/includes/DenyListManager.php#L181-L187
And will add the whole deny list to this IPSet object
GitHub
mediawiki-extensions-StopForumSpam/DenyListManager.php at 950d636ebde9f7846648967aade0ee8db6a80ab0 · wikimedia/mediawiki-extensions-StopForumSpam
Github mirror of MediaWiki extension StopForumSpam - our actual code is hosted with Gerrit (please see https://www.mediawiki.org/wiki/Developer_access for contributing - mediawiki-extensions-StopF...
3:40 PM

Its around 72k IP addresses that it adds to this IPSet
3:40 PM

and it'll do this once per request where this SFS code patch is called, 
even if cached), and maybe that takes some time to do this, possibly made worse by CPU restrictions 
3:43 PM

Side note, there is also work moving towards deploying this on WMF production :slightly_smiling_face: https://phabricator.wikimedia.org/T273220
3:46 PM

Without doing any more advanced investigation, I suspect that

0) Could add a simple log message that outputs in wikibase.cloud production timing how long generating this IPSet takes
1) We would want to make sure that there is enough room in redis so that this global cache key (shared between all wikis) of the list if IPs doesnt get booted out too often.
2) It might be possible to change the extension to allow the cache to be configurable rather than just using the mw main cache
3) We may want to bump CPU limit for mediawiki so that it can do this bit of processing faster ( :warning: easiest way to see a performance gain I bet )
4) its possible the extension itself could have some optimization done

These are the interesting profiling outputs of Special:NewItem

name                                                                                                                 wallTime   wallTime%   wallTime1   ownTime    ownTime%   ownTime1   count
Wikimedia\IPSet::addCidr                                                                                             11.34s     73.71       42.6us      8.04s      52.25      30.2us     266K 
curl_exec                                                                                                            1.58s      10.28       790.72ms    1.58s      10.27      790.45ms   2    
MediaWiki\StopForumSpam\Hooks::onGetUserPermissionsErrorsExpensive                                                   12.87s     83.67       2.15s       887.02ms   5.77       147.84ms   6    
Wikimedia\AtEase\AtEase::suppressWarnings                                                                            945.15ms   6.14        1.8us       801.14ms   5.21       1.5us      533K 
array_map                                                                                                            860.74ms   5.59        3.2us       641.9ms    4.17       2.4us      266K 
str_split                                                                                                            481.19ms   3.13        1.8us       481.19ms   3.13       1.8us      266K 
Wikimedia\AtEase\AtEase::quietCall                                                                                   1.73s      11.23       6.5us       466.32ms   3.03       1.8us      266K 
mysqli::query                                                                                                        461.3ms    3           2.71ms      461.3ms    3          2.71ms     170  
Wikimedia\IPSet::__construct                                                                                         11.73s     76.21       2.93s       384.57ms   2.5        96.14ms    4    
Wikimedia\AtEase\AtEase::restoreWarnings                                                                             811.65ms   5.28        3us         254.87ms   1.66       1us        266K 
explode

Change 824415 had a related patch set uploaded (by Addshore; author: Addshore):

[mediawiki/extensions/StopForumSpam@master] Fix DenyListManager singleton

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

Change 824415 merged by jenkins-bot:

[mediawiki/extensions/StopForumSpam@master] Fix DenyListManager singleton

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

Change 824184 had a related patch set uploaded (by Reedy; author: Addshore):

[mediawiki/extensions/StopForumSpam@REL1_38] Fix DenyListManager singleton

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

Change 824185 had a related patch set uploaded (by Reedy; author: Addshore):

[mediawiki/extensions/StopForumSpam@REL1_37] Fix DenyListManager singleton

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

Change 824426 had a related patch set uploaded (by Reedy; author: Addshore):

[mediawiki/extensions/StopForumSpam@wmf/1.39.0-wmf.25] Fix DenyListManager singleton

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

Change 824185 merged by jenkins-bot:

[mediawiki/extensions/StopForumSpam@REL1_37] Fix DenyListManager singleton

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

Change 824426 merged by jenkins-bot:

[mediawiki/extensions/StopForumSpam@wmf/1.39.0-wmf.25] Fix DenyListManager singleton

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

Change 824184 merged by jenkins-bot:

[mediawiki/extensions/StopForumSpam@REL1_38] Fix DenyListManager singleton

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

Anton.Kokh claimed this task.
Anton.Kokh subscribed.

We believe this can be closed, because the actions currently take well under 1 second