Writer performance with lots of users

[mmeeks]

Seems we get some performance problems - with new users joining (perhaps). perf.txt

Seems there are a number of issues here: rendering styles, compressing bitmaps and so on.

[eszkadev]

related commit:

commit 522bde9470bbb321813fa5f1ca8e3c2ebb1bb5cc Author: Szymon Kłos szymon.klos@collabora.com Date: Tue Dec 14 18:21:39 2021 +0100

Update styles previews in Idle

https://cgit.freedesktop.org/libreoffice/core/commit/?id=522bde9470bbb321813fa5f1ca8e3c2ebb1bb5cc

have to check why we start that timer very often

[eszkadev]

patch trying to cache our style preview renders: https://gerrit.libreoffice.org/c/core/+/152556

[mmeeks]

We just collaboratively edited some minutes with 7 users on staging.eu - and got the attached trace (over many minutes this time - with a low frequency sampling) - of a generic editing session. perf-editing.txt

[mmeeks]

Weirdly that trace spends lots of time in 'load' which seems very unexpected for a plain text document with next to nothing in it ;-) In fact the trace above is for a completely un-related process not doing editing (it seems).

[mmeeks]

And a better trace - with a few users editing minutes etc, in a debugging build etc. etc. we really need to profile a proper release build on a demo server I think perf-editing.txt Here is that as a flame-graph: Which looks much more sensible - at least we're not spending lots of time style preview rendering =)

[mmeeks]

Curious - reading the profile more - it seems we spend quite a lot of time sending entirely new keyframes to the client, and not building/sending the (much smaller) deltas; which is rather curious. It would be useful to look at the tripple-click help accounting in each tile for which tiles are getting new keyframes instead of deltas: there should be counts in each. Screenshot appreciated @timar =)

[caolanm]

FWIW, this is what I get on a trying to record from start of pseudo-join of 15 new users on the asan staging server until things become responsive again.

[mmeeks]

New trace from today's call. Looks rather unexpected

[caolanm]

https://gerrit.libreoffice.org/c/core/+/152719 is an idea for the OutputDevice::DrawTransparent issue which might work out

[caolanm]

Update of a simulated multi-user join with the newly shrunk removeCallbackDuplicate, but I still see some style preview generation which is annoying. Interacting with the 1st session while the others join seems to be able to trigger the notebookbar to be destroyed and replaced (tdf#155720) which clears that style preview cache.

https://gerrit.libreoffice.org/c/core/+/152720 to workaround that and https://github.com/CollaboraOnline/online/pull/6547 to elide a few more std::strings ctors

[mmeeks]

Nice work =)

[caolanm]

What todays save looked like

And join, as a png for size reasons here

[mmeeks]

Oooh - save performance is dominated by the thumbnail generate; and yet - that could easily run safely in another thread while the rest of the real save is going on - surely ? =) That thing is also single threaded which is unexpected; normally our large scale-downs (and we do have to render it big and then scale it down) - are threaded surely ? not sure what's up there. But I guess the larger win would be if we could do "thread thumbnail compression while saving" in the background I think =)

[mmeeks]

Seems like we fixed the lots-of-joiners problem; and the style preview bits - and also killed the big invalidations on new users joining - which is great =)