Server error caused by very poor performance when many images are stacked

[ErBerta]

The bug

The error below occurs in immich_server when I try to load the default library (about 30.000 elements).
After many attempts to solve the problem, I notice that hiding some of them (setting isVisible false in the database) reduced the loading time of GET /api/assets by a lot, from more than 20 seconds to 9.

I have noticed that in the excluded time periods i have a lot of stacked pictures, and some contains more than 500 photos.
I don't know if it's because thoose foto are also in a album or what, but by removing the stack it started working again.

The OS that Immich Server is running on

Ubuntu 22.04.4

Version of Immich Server

v1.102.3

Version of Immich Mobile App

v1.102.2 build.135

Platform with the issue

• Server
• Web
• Mobile

Your docker-compose.yml content

name: immich

services:
  immich-server:
    container_name: immich_server
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    command: [ "start.sh", "immich" ]
    volumes:
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
      - /etc/localtime:/etc/localtime:ro
    env_file:
      - .env
    ports:
      - 2283:3001
    depends_on:
      - redis
      - database
    restart: always

  immich-microservices:
    container_name: immich_microservices
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    command: [ "start.sh", "microservices" ]
    volumes:
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
      - /etc/localtime:/etc/localtime:ro
    env_file:
      - .env
    depends_on:
      - redis
      - database
    restart: always

  immich-machine-learning:
    container_name: immich_machine_learning
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
    volumes:
      - model-cache:/cache
    env_file:
      - .env
    restart: always

  redis:
    container_name: immich_redis
    image: registry.hub.docker.com/library/redis:6.2-alpine@sha256:84882e87b54734154586e5f8abd4dce69fe7311315e2fc6d67c29614c8de2672
    restart: always

  database:
    container_name: immich_postgres
    image: registry.hub.docker.com/tensorchord/pgvecto-rs:pg14-v0.2.0@sha256:90724186f0a3517cf6914295b5ab410db9ce23190a2d9d0b9dd6463e3fa298f0
    env_file:
      - .env
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_DB: ${DB_DATABASE_NAME}
    volumes:
      - ${DB_DATA_LOCATION}:/var/lib/postgresql/data
    ports:
      - 5432:5432
    restart: always

volumes:
  model-cache:

networks:
  default:
    external: true
    name: proxiable

Your .env content

###################################################################################
# Database
###################################################################################

# NOTE: The following four database variables support Docker secrets by adding a *_FILE suffix to the variable name
# See the docker-compose documentation on secrets for additional details: https://docs.docker.com/compose/compose-file/compose-file-v3/#secrets
DB_HOSTNAME=immich_postgres
DB_USERNAME=postgres
DB_PASSWORD=postgres
DB_DATABASE_NAME=immich
DB_DATA_LOCATION=/mnt/md0/immich-db/

###################################################################################
# Redis
###################################################################################

REDIS_HOSTNAME=immich_redis

###################################################################################
# Upload File Location
#
# This is the location where uploaded files are stored.
###################################################################################

UPLOAD_LOCATION=/mnt/md0/immich-data/

Reproduction steps

1. Stack a lot of images togheter 
2. (Maybe) Add the same images to an album
3. Try to load the library from a new device / clear installation of the app

Relevant log output

[Nest] 8 - 04/24/2024, 3:51:17 pm VERBOSE [Logginglnterceptor] [z6kbh2t9] GET /api/user/me 200 227.69m
[Nest] 8 - 04/24/2024, PM VERBOSE [Logginglnterceptor] [9rzk1w96] GET /api/server—info 200 257.71
[Nest] 8 - OU/2U/202U, 3:52:52 PM VERBOSE [Logginglnterceptor] [82ppwafd] GET /api/asset 200 223310.57ms
[Nest] 8 04/24/2024, PM ERROR [ExceptionsHandIer] [82ppwafd] Invalid string length
RangeError : Invalid string length
at JSON. stringify (<anonymous>)
at stringify (/usr/src/app/node_modules/express/lib/response. js:1159: 12)
at ServerResponse. json (/usr/src/app/node_modules/express/lib/response.
at ExpressAdapter.rep1y
at RouterResponseContr011er.appIy (/usr/src/app/node_moduIes/@nestjs/core/router/router—response—contr011er.js:15:36)
at /usr/src/app/node_modules/@nestj s/core/router/router—execution—context.js:176:118
at process. processTicksAndRejections (node: internal/process/task_queues : 95: 5)
at async /usr/src/ap /node_modules/@nestjs/core/router/router—execution—context.
at async /usr/src/app/node_moduIes/@nestjs/core/router/router—proxy.js:9:17

[mertalev]

I haven't looked at the asset payloads in a bit, but I suspect there might be duplication in the response in the case of stacked assets, etc. If each asset contains its stack in the response, then it's essentially going to explode the response size when the stack is big. Same with albums.

[bo0tzz]

That assessment is correct, the /api/asset response contains a full nested asset object for each member of the stack. The (deprecated) /api/assets response doesn't contain them.