Very slow response time when saving page

[FireSpike0]

Describe the Bug

If a page contains a very long table, the response time increases to very high values (>=30s). This leads to request timeouts with HTTP server errors (500) and thus discarded changes.

What I did to temporary solve the issue was adding the following line to the public/.htaccess file, which increases the PHP request timeout:

# Increase PHP execution time to prevent timeouts on write
php_value max_execution_time 60

Steps to Reproduce

1. Create a page with a long table (in our case: about 300 rows; 4 columns; with code formatting within cells).
2. Save the page.
3. Wait until page is probably saved (and measure request time).
4. If the timeout of the webserver is exceeded, the query is discarded.

Expected Behaviour

Shorter response times comparable to other pages without long tables.

Screenshots or Additional Context

Interestingly the timeout is always produced by the exact same line of code, which is according to the logs:

[2022-01-01 00:00:00] production.ERROR: Maximum execution time of 30 seconds exceeded (...) at /var/www/bookstack/app/Entities/Tools/PageContent.php:231)

The $xpath->query('//body//*//*[@href="' . $old . '"]') call seems to cause the problem in combination with many HTML elements, which is the case when using large HTML tables.

Browser Details

No response

Exact BookStack Version

v22.11.1

PHP Version

No response

Hosting Environment

Debian 11 with Apache HTTPD (probably shouldn't matter much).

[Ainillia]

Hello,

Adding weight on this.

I have the very same issue, but with regular content, not especially tables. Bookstack timeout while saving larger pages. However my install is on docker and i can't modifiy the docker config as it resets on every new deployment. I cannot save larger pages and documentation because of this.

I have 502 errors for saving the larger pages and also saing the dafts do timeout too (saving the draft failed, check internet connection...)

Laravel log (multiple entries like this one) :
[2023-01-06 11:52:17] production.ERROR: Maximum execution time of 30 seconds exceeded {"userId":1,"exception":"[object] (Symfony\Component\ErrorHandler\Error\FatalError(code: 0): Maximum execution time of 30 seconds exceeded at /app/www/app/Entities/Tools/PageContent.php:205)
[stacktrace]
#0 {main}

Steps for reproducing on my end :

• Create a brand new book & create a page on a new deployment.
• Write some stuff, validate that the draft & page is saving.
• (Example content) Open https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/9.1_release_notes/index and copy/paste the main body of this documentation to the bookstack page. You can also copy/paster the first 5 chapters (about half of the content), it will do the same.
• Wait for the draft saving or save the page manually
• The draft will fail and the page save will also fail with 502 error (an unknown error occurred), dropping the edits.
• The message above will be displayed in laravel.log, on PageContent.php line 231 or 205.

OS : RHEL 8.7 (also tried on Ubuntu 22.10)
Bookstack install : docker (followed Youtube tutorial for docker install with ngnix proxy)
Docker version : 20.10.22
Container version : 05.01.23 https://hub.docker.com/r/linuxserver/bookstack
Bookstack Version : 22.11.1

[ssddanbrown]

Thanks both for reporting and thanks @Ainillia for providing example reproduction content, that was very useful.

I spent some time on this today and found a few significant inefficiencies in the handling of HTML content on save, primarily:

• Links were queried and updated for each ID change to be made in content.
• Our targeting of elements for ID updating would overlap, meaning double or triple processing of elements in some cases (Which than exacerbated the above).
• We had a few large x path queries at play to target elements.

These have now been updated within commit 3149575, to use a more manual traversal approach that should have linear performance scaling (As expected) and address the above inefficiencies.

These changes will be part of the next feature release.

[0xbbeer]

@ssddanbrown Good news. Thank You!