mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-07-16 05:33:49 +03:00
UI loads painfully slow - bookstack hosted in a docker swarm #5438
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 @kMutagene on GitHub (Sep 26, 2025).
Attempted Debugging
Searched GitHub Issues
Describe the Scenario
We host bookstack on a docker swarm for our internal wiki, and it has painfully slow UI load times. This does not happen everytime, but if it does, especially when opening the editor it makes it next to unusable.
https://github.com/user-attachments/assets/cde51061-a1b2-4868-a299-2afbfbf89740
I have seen https://github.com/BookStackApp/BookStack/issues/5385 but that does not solve the issue.
We then tried to add redis for caching but doing it as described in the docks does not seem to do anything (we also do not see anything happening in the redis logs)
Any pointers of what to try to make it work are highly appreciated, and thank you very much for this project, when it works it is awesome.
cc @freymaurer
Exact BookStack Version
v25.07.2
Log Content
Hosting Environment
Docker swarm via docker compose
@ssddanbrown commented on GitHub (Sep 27, 2025):
Hi @kMutagene,
Judging by that video clip, it looks like the actual app HTML response is what's slow, which is very uncommon.
This is based on the book tiles appearing one-by-one.
Don't think this is a caching or even database issue, since most fetching of the data slowing loading would already be done.
I'm not familiar enough with swarm to know if there's particular swarm-based things which may impact performance like this.
@Freymaurer commented on GitHub (Sep 27, 2025):
Hey @ssddanbrown ! I am working with @kMutagene and can give some insight 🙂
The following is part of the docker-compose file we have set up
docker-compose
The docker-swarm is controlled by our tech center, but in other apps this had not created performance issues (altough those were very client side heavy)
Would have to ask to knwo what exactly 😞
The overall logs are only ~200 lines long, so i'll just paste them here. Let me know if you referred to something else!
Details
Difficult to say. Sometimes it the content is there in an instant and sometimes it takes for ever. Here are some screenshots showing load times:
Here are some things i noticed when accessing the stack for these images.
Of course all of this might have been by chance 🤷
To check for this i navigated to a specific page by clicking through shelves -> books in shelve -> page -> edit
And just after typing this out, everything was fast 100%... But for the images nearly all requests were between 4-10s
@ssddanbrown commented on GitHub (Sep 30, 2025):
Thanks for all the extra information @Freymaurer.
It's hard to say exactly what might be happening here without being able to dig much deeper into the exact container and networking and web server behaviour.
I'm wondering whether in this form configuration containers are being dynamically created and destroyed on demand, And therefore these pauses are the delays waiting for a new container to start up. There are some significant startup steps on the container image views, since it's not really designed to be utilized for an on-demand scenario, which could represent the four to ten second range that you're seeing.
Again, I'm not too familiar with how Docker Swarm works, but would it be possible to set the Swarm configuration for the BookStack container so that there's only one instance continuously running and therefore remove any dynamic behavior in terms of container management. Then you could see if you end up with a more stable environment without these very slow responses. This should help either rule out or identify if the cause is related to dynamic container start-up/use behaviour.