Very slow response time when saving page #3412

New Issue

OVERLORD · 2026-02-05T06:38:16+03:00

OVERLORD commented

2026-02-05 06:38:16 +03:00

Originally created by @FireSpike0 on GitHub (Dec 27, 2022).

Originally assigned to: @ssddanbrown on GitHub.

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

Create a page with a long table (in our case: about 300 rows; 4 columns; with code formatting within cells).
Save the page.
Wait until page is probably saved (and measure request time).
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).

Originally created by @FireSpike0 on GitHub (Dec 27, 2022). Originally assigned to: @ssddanbrown on GitHub. ### 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).

OVERLORD added the 🐛 Bug label 2026-02-05 06:38:16 +03:00

OVERLORD closed this issue

2026-02-05 06:38:18 +03:00

OVERLORD commented

2026-02-05 06:38:20 +03:00

@Ainillia commented on GitHub (Jan 6, 2023):

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

@Ainillia commented on GitHub (Jan 6, 2023): 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

OVERLORD commented

2026-02-05 06:38:21 +03:00

@ssddanbrown commented on GitHub (Feb 22, 2023):

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 31495758a9, 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.

@ssddanbrown commented on GitHub (Feb 22, 2023): 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 31495758a9459d13d6dd4718262c23f7f763bc92, 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.

OVERLORD commented

2026-02-05 06:38:24 +03:00

@0xbbeer commented on GitHub (Feb 23, 2023):

@ssddanbrown Good news. Thank You!

@0xbbeer commented on GitHub (Feb 23, 2023): @ssddanbrown Good news. Thank You!

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#3412