Performance Degradation on Large Pages

[carlossierra311]

Attempted Debugging

• [X] I have read the debugging page

Searched GitHub Issues

• [X] I have searched GitHub for the issue.

Describe the Scenario

I have a page I consider large (but not unusual in our context), with 29.000+ words, 183.000+ characters, 1.400 lines of code divided in 27 code blocks and 5 images. When I try to edit the page, it takes more than 10 seconds every time for the first character to appear on screen, and every consecutive edit takes the same time.

I already tried this tip, and it improved the response time (before, every edit could take close to one minute), but it's still unsustainable.

With smaller pages, performance is quite good, and the application feels very responsive.

Is there anything else that can be done to further improve performance to usable levels?

Exact BookStack Version

v22.11.1

Log Content

No response

PHP Version

8.1.10

Hosting Environment

Windows Server 2019 Standard v1809, OS build 17763.3406 32 GB Ram, Intel Xeon E3-1230 v5 @3.4GHz

BookStack installed manually by following these steps, using the following components: php-8.1.10 mysql-8.0.30 nginx-1.23.1

Memory usage is usually around 50% (this server is used to host a couple other applications), and CPU usage is around 5%, even during the reported behavior.

[ssddanbrown]

Hi @carlossierra311,

The reality is, there will always be some level of limit to length of content before it affects part of a system. While it may be possible to add measures to break things down, doing so adds complexity that probably wouldn't be worthwhile if such issues only exist in minor edge/use-cases.

That said, we can try to look at the current bottleneck to see if that can be improved. Based on your info, this is likely going to be directly related to the browser-side code and specifically the editor.

These kinds of things can be very content-specific, is there any chance you could provide a faithful, yet anonymized if required, example of page content that you experience this degradation for? If using the WYSIWYG editor one of the right-most buttons in the toolbar allows viewing the source. Also, please confirm if you're using the default WYSIWYG editor or the markdown editor.

[carlossierra311]

Thank you @ssddanbrown for your reply. I managed to reproduce the same behavior by creating a new document and pasting the contents of this page on it (I copied the content up to the See also section, and left out the rest from there on). After that, if I try to start editing the content, the long lag starts to occur.

I am using the WYSIWYG editor. Please let me know if you need any other information from my side.

[carlossierra311]

By the way, I just noticed the lag is starting to appear in a new smaller document I'm working on, with only 2 images, no code blocks, 5457 words and 35.088 characters.

[ssddanbrown]

Thanks for the example @carlossierra311, I'll look into this once I get some time to do so. Since this is client-side performance, would you be able to confirm the your own computer specs, operating system and browser in use? Just to give a reference point.

[carlossierra311]

Thanks @ssddanbrown. Here you go:

• Computer specs:
  • CPU: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz 2.59 GHz
  • RAM: 16.0 GB
  • OS Disk: 480GB NVMe M.2.
  • Data Disk: 2TB SSD.
• OS: Windows 10 Pro 22H2 (19045.2546)
• Chrome: 109.0.5414.75 (Official build) (64 bits)

[0xbbeer]

Hello! I have same issue with large page that contains tables and text content ( all around 127000 symbols). Saving that page take more than 5 minutes. I was trying save content in markdown and html, from browser's and by API, but result was the same.

OS: Debian 11 WebServer: Apache PHP: 7.4.33 Bookstack Version: 22.11 CPU: 4vCPU (when page saving, one of 4 CPU load to 100%) RAM: 4G

laravel.log `[2023-02-14 06:44:35] production.ERROR: Maximum execution time of 520 seconds exceeded {"userId":15,"exception":"[object] (Symfony\Component\ErrorHandler\Error\FatalError(code: 0): Maximum execution time of 520 seconds exceeded at /var/www/bookstack/app/Entities/Tools/PageContent.php:231) [stacktrace]

0 {main}

"} `

[ssddanbrown]

@0xbbeer Issue #3932 is more relevant to your scenario since this thread looks to be client-side, whereas your issue is server-side.

[ssddanbrown]

I've been testing this today. From my testing this part of the code is relatively inefficient and becomes a bottleneck on larger pages to introduce lag upon change.

Currently we're fetching the editor content upon any change then communicating that up to the parent page editor component, so it can manage auto-saving. Think this could be changed so that the content itself is not communicated on every change, but instead just the event itself to indicate a change has occured, then we should fetch the content only when actually needed.

There'd probably still be some level of lag on auto-save (that would be much trickier to address) but that would only be every 30s or so (and commonly not while making changes I'd imagine) and doing the above should improve things massively with reasonable effort. I'll assign this to the next feature release.

[carlossierra311]

Thanks @ssddanbrown. Sounds good, from an end user's perspective.

Just one thought: what about making the auto save period configurable, so that we can increase it to 1 or 2 minutes, to balance the lag (decreased content creation productivity) with the potential work loss?

[ssddanbrown]

@carlossierra311 That would be possible but I'd prefer to limit options where possible to keep maintainability reasonable.

I'll do the above as a significant improvement. If the auto-save lag really is problematic, based on actual experience after the above has been done, then that could then be raised as a separate issue.

[carlossierra311]

Sounds good. Thanks @ssddanbrown.

[ssddanbrown]

This has now been addressed within commit 6545afacd69bbb1d13e4e4c97da84004789a99e8, and will be part of the next feature release. I'll therefore close this off.