mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-13 03:13:58 +03:00
Performance Degradation on Large Pages #3462
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @carlossierra311 on GitHub (Jan 19, 2023).
Originally assigned to: @ssddanbrown on GitHub.
Attempted Debugging
Searched GitHub Issues
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 commented on GitHub (Jan 26, 2023):
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 commented on GitHub (Jan 27, 2023):
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 commented on GitHub (Jan 27, 2023):
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 commented on GitHub (Jan 27, 2023):
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 commented on GitHub (Jan 27, 2023):
Thanks @ssddanbrown. Here you go:
@0xbbeer commented on GitHub (Feb 14, 2023):
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 commented on GitHub (Feb 14, 2023):
@0xbbeer Issue #3932 is more relevant to your scenario since this thread looks to be client-side, whereas your issue is server-side.
@ssddanbrown commented on GitHub (Feb 22, 2023):
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 commented on GitHub (Feb 23, 2023):
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 commented on GitHub (Feb 23, 2023):
@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 commented on GitHub (Feb 23, 2023):
Sounds good. Thanks @ssddanbrown.
@ssddanbrown commented on GitHub (Feb 23, 2023):
This has now been addressed within commit
6545afacd6, and will be part of the next feature release. I'll therefore close this off.