[BUG] Album Page takes way to long to load

[akoyaxd]

The bug

If I open the Albumlist with currently about 7 Albums it takes about 6 seconds to load each time I open the Album overview or return from an Album. It looks like it takes so long to generate the json with with Album Info.

Maybe there could be some caching or optimization on how the Album Page is rendered.

The OS that Immich Server is running on

Debian 11 with Docker

Version of Immich Server

v1.49.0

Version of Immich Mobile App

v1.49.0

Platform with the issue

• [X] Server
• [X] Web
• [ ] Mobile

Your docker-compose.yml content

version: "3.3"

volumes:
  immich_data:
    external: true

services:
  server:
    image: altran1502/immich-server:release
    entrypoint: ["/bin/sh", "./start-server.sh"]
    volumes:
      - immich_data:/usr/src/app/upload
    environment:
      - NODE_ENV=production
      - DB_HOSTNAME=postgres
      - DB_USERNAME=postgres
      - DB_PASSWORD=${DB_PASSWORD}
      - DB_DATABASE_NAME=immichdb
      - REDIS_HOSTNAME=redis
      - JWT_SECRET=${JWT_SECRET}
      - ENABLE_MAPBOX=false
      - MAPBOX_KEY=${MAPBOX_KEY}
      - PUBLIC_LOGIN_PAGE_MESSAGE="Immich Instance des Koyax Project"
      - ENABLE_MAPBOX=true
    env_file:
      - env
    hostname: immich-server
    depends_on:
      - redis
      - postgres
    restart: unless-stopped

  microservices:
    image: altran1502/immich-server:release
    entrypoint: ["/bin/sh", "./start-microservices.sh"]
    volumes:
      - immich_data:/usr/src/app/upload
    environment:
      - NODE_ENV=production
      - DB_HOSTNAME=postgres
      - DB_USERNAME=postgres
      - DB_PASSWORD=${DB_PASSWORD}
      - DB_DATABASE_NAME=immichdb
      - REDIS_HOSTNAME=redis
      - JWT_SECRET=${JWT_SECRET}
      - ENABLE_MAPBOX=false
      - MAPBOX_KEY=${MAPBOX_KEY}
      - PUBLIC_LOGIN_PAGE_MESSAGE="Immich Instance des Koyax Project"
      - ENABLE_MAPBOX=true
    env_file:
      - env
    depends_on:
      - redis
      - postgres
    restart: unless-stopped
    hostname: immich-microservices
    deploy:
      resources:
        limits:
          cpus: '4.0'
          memory: 4G

  machine-learning:
    image: altran1502/immich-machine-learning:release
    command: [ "python", "src/main.py" ]
    volumes:
      - immich_data:/usr/src/app/upload
      - /opt/immich-ml/cache:/cache
    environment:
      - NODE_ENV=production
      - DB_HOSTNAME=postgres
      - DB_USERNAME=postgres
      - DB_PASSWORD=${DB_PASSWORD}
      - DB_DATABASE_NAME=immichdb
      - REDIS_HOSTNAME=redis
      - JWT_SECRET=${JWT_SECRET}
      - PUBLIC_LOGIN_PAGE_MESSAGE="Immich Instance des Koyax Project"
    env_file:
      - env
    depends_on:
      - postgres
    restart: unless-stopped
    hostname: immich-machine-learning

  web:
    image: altran1502/immich-web:release
    entrypoint: ["/bin/sh", "./entrypoint.sh"]
    environment:
      - DB_HOSTNAME=postgres
      - DB_USERNAME=postgres
      - DB_PASSWORD=${DB_PASSWORD}
      - DB_DATABASE_NAME=immichdb
      - REDIS_HOSTNAME=redis
      - JWT_SECRET=${JWT_SECRET}
      - ENABLE_MAPBOX=false
      - MAPBOX_KEY=${MAPBOX_KEY}
      - PUBLIC_LOGIN_PAGE_MESSAGE="Immich Instance des Koyax Project"
      - ENABLE_MAPBOX=true
    env_file:
      - env
    restart: unless-stopped
    hostname: immich-web

  redis:
    image: redis:6
    restart: unless-stopped
    hostname: immich_redis

  postgres:
    image: postgres:14
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_DB: ${DB_DATABASE_NAME}
      PG_DATA: /var/lib/postgresql/data
    env_file:
      - env
    volumes:
      - /opt/immich-postgres:/var/lib/postgresql/data
    restart: unless-stopped
    hostname: immich_postgres

  proxy:
    image: altran1502/immich-proxy:release
    ports:
      - 2283:8080
    depends_on:
      - server
    restart: unless-stopped

Your .env content

only secrets

Reproduction steps

1. Install Immich
2. Create Albums
3. Open Albums Page
...

Additional information

No response

[raisinbear]

What's your architecture? Do you see anything along the lines immich_postgres | ORC error: No callback manager available for [XYZ] in the logs / output? For me this was the case and when opening the albums overview (among others), a lot of CPU was consumed by postgres for a couple of seconds before the page would finally load. I kind of mitigated the issue by specifing jit = off # allow JIT compilation in the relevant - by default commented - line in the postgresql.conf file in the postgres docker volume. It's still slow - and I have the feeling slower than it was a couple of revisions before - but faster now by at least three to four seconds, as the postgres process isn't blocking anymore.

[akoyaxd]

I actually see a lot of CPU Usage of Postgres, when opening the Album overview. Though I can not find the error message you mentioned in the logs..

[michelheusschen]

I know of some album queries that are pretty unoptimized. Are you viewing the page with all albums or selecting a specific album? And could you share how many albums/assets you have and how many assets are in albums? Doesn't have to be exact, just to get a general idea.

[akoyaxd]

I currently have 15 albums with mostly ~150 Assets. One has 1100 assets. Yea, I view the page with all Albums. Opening an Album is reasonable in therms of velocity. Even the large one with 1100 assets.

[raisinbear]

Actually, I don't know if the error itself was the reason for the high cpu load. However, some digging led me to turn of jit, which resolved both error message and cpu load. In case you try this, you have to restart the postgres container.

[raisinbear]

I just checked again, haven't used the web interface too much recently. Opening the album overview (or merely hovering over the information icon next to the button) really takes quite long. My server is on the weak side, that's why it's probably more noticeable. The jit parameter mentioned earlier takes loading time down from over 9 seconds to roughly 4 seconds for me, but that is still a lot. docker stats shows the postgres container being active for less than a second at roughly 25% CPU load then. The rest of the time is consumed by immich server at full load. I'm very certain that hasn't been the case a few iterations back, (say late December) and I've barely added any assets in the mean time. I'll try to dive in deeper when I have time, but I fear all I can do is find the last version that performed snappy for me. Don't know if that helps.

[titro]

can confirm that since 1.48 (i guess so). Perhaps related to 1582 ?

[SitramSoft]

I'd really like to use this app, but with over 35k pictures its so slow that I can barely use it. Just loading all 30 albums I have on web interface takes over 30 seconds. Opening the album that has the most photos(~19k) takes close like 2 minutes on web interface. I really hope app maintainer will schedule a release with some optimizations on the current infrastructure to be usable on large albums, otherwise as awesome this app is, it won't be usable unless you have a small photo library.

[alextran1502]

I'd really like to use this app, but with over 35k pictures its so slow that I can barely use it. Just loading all 30 albums I have on web interface takes over 30 seconds. Opening the album that has the most photos(~19k) takes close like 2 minutes on web interface. I really hope app maintainer will schedule a release with some optimizations on the current infrastructure to be usable on large albums, otherwise as awesome this app is, it won't be usable unless you have a small photo library.

Yeah this is the regression from the latest refactor. We are aware of the issue and planning to address this in the upcoming release