UI loads painfully slow - bookstack hosted in a docker swarm

[kMutagene]

Attempted Debugging

• I have read the debugging page

Searched GitHub Issues

• I have searched GitHub for the issue.

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.

20250926-1404-38.8775456.mp4

I have seen #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]

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.

• Is the app container performance limited/controlled in any way?
• Is there a HTTP proxy system involved?
• Do the webserver access logs, in the app container, reflect these long response times?
  • If unsure where to find this, let me know which image you're using.
• Any pattern to when this occurs?
• How frequently does this happen? (Almost all? Half of all requests? Just the first then it's fine for a while? etc...)

[Freymaurer]

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

version: '3'

volumes:
  csb_bookstack_db:
  csb_bookstack_config:

services:

  csbookstack-db:                      # MariaDB database service (officially recommended for BookStack)
    image: mariadb:10.11               # Use stable MariaDB version 10.11 from registry
    container_name: csbookstack_db    # Name of the DB container
    command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
                                       # Recommended flags for BookStack: ensure safe transactions and binlog format
    environment:                       # Environment variables for MariaDB
      MYSQL_ROOT_PASSWORD: "pwRoot"  # Root password (admin access to the DB)
      MYSQL_DATABASE: csbookstackapp   # Database to create at first startup
      MYSQL_USER: user1 # Application DB user
      MYSQL_PASSWORD: "pw1"   # Password for the DB user (use something secure)
    volumes:                           # Persist database data to the host
      - csb_bookstack_db:/var/lib/mysql

    restart: unless-stopped             # Always restart unless explicitly stopped

  csbookstack-redis:
    image: redis:8.2.1-alpine
    container_name: csbookstack_redis

  csbookstack:                           # BookStack application service
    image: lscr.io/linuxserver/bookstack:latest   # LinuxServer.io BookStack image
    container_name: csbookstack          # Name of the app container

    environment:                       # Environment variables configuring BookStack
      CACHE_DRIVER: redis
      SESSION_DRIVER: redis
      REDIS_SERVERS: csbookstack-redis:6379:0
      PUID: "1000"                     # User ID for file ownership (match your host UID)
      PGID: "1000"                     # Group ID for file ownership (match your host GID)
      APP_URL: "https://csb-bookstack.bio.rptu.de" # Public URL where BookStack will be accessed (set to your domain in production)
      DB_HOST: csbookstack-db          # Hostname of the DB service (matches service name above)
      DB_PORT: "3306"                  # MariaDB default port
      DB_DATABASE: csbookstackapp        # Database name (must match MYSQL_DATABASE above)
      DB_USERNAME: bookstack           # DB username (must match MYSQL_USER above)
      DB_PASSWORD: "pw1"        # DB password (must match MYSQL_PASSWORD above)
      APP_KEY: "base64:placeholder"
                                       # Your unique Laravel app key (ensures encryption & sessions work)
    volumes:                           # Persist BookStack config/uploads/themes
      - csb_bookstack_config:/config
    ports:                             # Expose BookStack UI
      - "11111:80"                     # Map host port 11111 → container port 80

Is the app container performance limited/controlled in any way?

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)

Is there a HTTP proxy system involved?

Would have to ask to knwo what exactly 😞

Do the webserver access logs, in the app container, reflect these long response times?

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

[migrations] started
[migrations] started
[migrations] 01-nginx-site-confs-default: skipped
[migrations] 01-nginx-site-confs-default: skipped
[migrations] started
[migrations] 02-default-location: skipped
[migrations] done
[migrations] 01-nginx-site-confs-default: skipped
───────────────────────────────────────
[migrations] started

[migrations] 02-default-location: skipped
      ██╗     ███████╗██╗ ██████╗
[migrations] 01-nginx-site-confs-default: skipped
      ██║     ██╔════╝██║██╔═══██╗
[migrations] 02-default-location: skipped
[migrations] done
[migrations] 02-default-location: skipped
[migrations] started
      ██║     ███████╗██║██║   ██║
[migrations] done
───────────────────────────────────────
[migrations] done
───────────────────────────────────────
      ██║     ╚════██║██║██║   ██║
───────────────────────────────────────

[migrations] 01-nginx-site-confs-default: skipped


      ██╗     ███████╗██╗ ██████╗
[migrations] 02-default-location: skipped
      ███████╗███████║██║╚██████╔╝
      ██╗     ███████╗██╗ ██████╗
      ██║     ██╔════╝██║██╔═══██╗
[migrations] done
      ╚══════╝╚══════╝╚═╝ ╚═════╝
      ██║     ██╔════╝██║██╔═══██╗
      ██║     ███████╗██║██║   ██║
───────────────────────────────────────

      ██║     ███████╗██║██║   ██║

      ██╗     ███████╗██╗ ██████╗
      ██║     ╚════██║██║██║   ██║
      ██╗     ███████╗██╗ ██████╗
   Brought to you by linuxserver.io
      ██║     ╚════██║██║██║   ██║
      ███████╗███████║██║╚██████╔╝
      ██║     ██╔════╝██║██╔═══██╗
───────────────────────────────────────
      ╚══════╝╚══════╝╚═╝ ╚═════╝
      ███████╗███████║██║╚██████╔╝
      ██║     ███████╗██║██║   ██║

      ╚══════╝╚══════╝╚═╝ ╚═════╝
      ██║     ██╔════╝██║██╔═══██╗

To support LSIO projects visit:

      ██║     ███████╗██║██║   ██║
   Brought to you by linuxserver.io
      ██║     ╚════██║██║██║   ██║
https://www.linuxserver.io/donate/
   Brought to you by linuxserver.io
───────────────────────────────────────
      ██║     ╚════██║██║██║   ██║
      ███████╗███████║██║╚██████╔╝
      ███████╗███████║██║╚██████╔╝
      ╚══════╝╚══════╝╚═╝ ╚═════╝
───────────────────────────────────────

      ╚══════╝╚══════╝╚═╝ ╚═════╝


To support LSIO projects visit:

───────────────────────────────────────

   Brought to you by linuxserver.io
   Brought to you by linuxserver.io
To support LSIO projects visit:
https://www.linuxserver.io/donate/
───────────────────────────────────────
───────────────────────────────────────


https://www.linuxserver.io/donate/
To support LSIO projects visit:

───────────────────────────────────────

https://www.linuxserver.io/donate/
To support LSIO projects visit:

───────────────────────────────────────
GID/UID
https://www.linuxserver.io/donate/
GID/UID
───────────────────────────────────────

───────────────────────────────────────
GID/UID

───────────────────────────────────────

───────────────────────────────────────
GID/UID
User UID:    1000
User UID:    1000
───────────────────────────────────────
User GID:    1000
User GID:    1000

───────────────────────────────────────
User UID:    1000
───────────────────────────────────────
User GID:    1000
───────────────────────────────────────
Linuxserver.io version: v25.07.2-ls220
───────────────────────────────────────
GID/UID
Build-date: 2025-09-22T18:33:50+00:00
Linuxserver.io version: v25.07.2-ls220
───────────────────────────────────────
Linuxserver.io version: v25.07.2-ls220
───────────────────────────────────────

    
Build-date: 2025-09-22T18:33:50+00:00
User UID:    1000
using keys found in /config/keys

User GID:    1000
Waiting for DB to be available
───────────────────────────────────────
User UID:    1000
───────────────────────────────────────
    

User GID:    1000
Linuxserver.io version: v25.07.2-ls220
using keys found in /config/keys
Build-date: 2025-09-22T18:33:50+00:00
───────────────────────────────────────
   INFO  Nothing to migrate.  

Linuxserver.io version: v25.07.2-ls220
[custom-init] No custom files found, skipping...
Build-date: 2025-09-22T18:33:50+00:00
Build-date: 2025-09-22T18:33:50+00:00
───────────────────────────────────────
───────────────────────────────────────
[ls.io-init] done.
    
    
using keys found in /config/keys
using keys found in /config/keys
───────────────────────────────────────
Waiting for DB to be available
    
Waiting for DB to be available

using keys found in /config/keys

   INFO  Nothing to migrate.  
Waiting for DB to be available
Waiting for DB to be available


[custom-init] No custom files found, skipping...
   INFO  Nothing to migrate.  


[ls.io-init] done.
   INFO  Nothing to migrate.  
[custom-init] No custom files found, skipping...
[ls.io-init] done.

[migrations] started
[custom-init] No custom files found, skipping...
[migrations] 01-nginx-site-confs-default: skipped
[ls.io-init] done.
[migrations] 02-default-location: skipped
[migrations] done
usermod: no changes
   INFO  Nothing to migrate.  
───────────────────────────────────────


[custom-init] No custom files found, skipping...
      ██╗     ███████╗██╗ ██████╗
      ██║     ██╔════╝██║██╔═══██╗
[ls.io-init] done.
      ██║     ███████╗██║██║   ██║
      ██║     ╚════██║██║██║   ██║
      ███████╗███████║██║╚██████╔╝
      ╚══════╝╚══════╝╚═╝ ╚═════╝

   Brought to you by linuxserver.io
───────────────────────────────────────

To support LSIO projects visit:
https://www.linuxserver.io/donate/

───────────────────────────────────────
GID/UID
───────────────────────────────────────

User UID:    1000
User GID:    1000
───────────────────────────────────────
Linuxserver.io version: v25.07.2-ls220
Build-date: 2025-09-22T18:33:50+00:00
───────────────────────────────────────
    
using keys found in /config/keys
Waiting for DB to be available

   INFO  Nothing to migrate.  

[custom-init] No custom files found, skipping...
[ls.io-init] done.

Any pattern to when this occurs?

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.

• The overall first few accesses were fast (not page specific)
• Switching between shelves and books sometimes is super fast and then without changing anything it suddenly takes 9 seconds
• Switching between new pages does seem to make it worse

Of course all of this might have been by chance 🤷

How frequently does this happen? (Almost all? Half of all requests? Just the first then it's fine for a while? etc...)

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]

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.