Saving a recipe takes longer than 20s

[igor-krechetov]

Tandoor Version

1.5.27

Setup

Docker / Docker-Compose

Reverse Proxy

Nginx Proxy Manager (NPM)

Other

No response

Bug description

Saving a recipe takes 20~22 seconds (based on Chrome debug console).
From what I can see in the logs, SQL query part takes at least 7.8s, but unclear where the remaining time is spent. Issue was observed from the moment I installed Tandoor.

The only related issue I was able to find seems to be discussed here: #2368

Instance Details

• Spaces: 1
• Recipies in the database: 42
• Instance of postgresql is not shared with other Docker containers.
• Debug mode is turned off.

Server details

• OS: OpenMediaVault 7.5
• Server is accessed through a 1 GigE network.
• There is at least 4Gb of RAM available on the server.
• During the save operation CPU consumption doesn't peak above 40% (with idle being around 3%)

Docker Compose configuration

services:
  db_recipes:
    container_name: tandoor-db
    restart: unless-stopped
    image: postgres:16-alpine
    env_file: "tandoor.env"
    volumes:
      - ${SERVICES_DATA_PATH?}/tandoor/postgresql:/var/lib/postgresql/data
    networks:
      - default

  web_recipes:
    container_name: tandoor
    restart: unless-stopped
    image: vabene1111/recipes
    env_file: "tandoor.env"
    volumes:
      - ${SERVICES_DATA_PATH?}/tandoor/staticfiles:/opt/recipes/staticfiles
      - ${SERVICES_DATA_PATH?}/tandoor/mediafiles:/opt/recipes/mediafiles
      - nginx_config:/opt/recipes/nginx/conf.d
    networks:
      - default
    depends_on:
      - db_recipes

  nginx_recipes:
    container_name: tandoor-nginx
    image: nginx:mainline-alpine
    restart: unless-stopped
    env_file: "tandoor.env"
    ports:
      - 8380:80
    depends_on:
      - web_recipes
    volumes:
      # Do not make this a bind mount, see https://docs.tandoor.dev/install/docker/#volumes-vs-bind-mounts
      - nginx_config:/etc/nginx/conf.d:ro
      - ${SERVICES_DATA_PATH?}/tandoor/staticfiles:/static:ro
      - ${SERVICES_DATA_PATH?}/tandoor/mediafiles:/media:ro

volumes:
  nginx_config:

Relevant logs

tandoor-nginx  | 111.222.333.444 - - [09/Feb/2025:12:32:03 +0000] "GET /api/user/ HTTP/1.1" 200 173 "https://xxx/edit/recipe/internal/3/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36" "aaa.bbb.ccc.ddd"
tandoor        | ::ffff:172.24.0.4 - - [09/Feb/2025:12:32:03 +0000] "GET /api/user/ HTTP/1.0" 200 173 "https://xxx/edit/recipe/internal/3/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36"
tandoor-nginx  | 2025/02/09 12:32:31 [warn] 21#21: *143 a client request body is buffered to a temporary file /var/cache/nginx/client_temp/0000000001, client: 111.222.333.444, server: localhost, request: "PUT /api/recipe/3/ HTTP/1.1", host: "xxx", referrer: "https://xxx/edit/recipe/internal/3/"
tandoor        | 
tandoor        |
tandoor        |   [SQL Queries for] /api/recipe/3/
tandoor        |
tandoor        |   [TOTAL TIME: 7.802000000000568 seconds]
tandoor        |   [TOTAL QUERIES: 5809]
tandoor        | ::ffff:172.24.0.4 - - [09/Feb/2025:12:32:51 +0000] "PUT /api/recipe/3/ HTTP/1.0" 200 35536 "https://xxx/edit/recipe/internal/3/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36"
tandoor-nginx  | 111.222.333.444 - - [09/Feb/2025:12:32:51 +0000] "PUT /api/recipe/3/ HTTP/1.1" 200 35536 "https://xxx/edit/recipe/internal/3/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36" "aaa.bbb.ccc.ddd"
tandoor-db     | 2025-02-09 12:33:15.122 UTC [27] LOG:  checkpoint starting: time
tandoor-db     | 2025-02-09 12:33:19.920 UTC [27] LOG:  checkpoint complete: wrote 49 buffers (0.3%); 0 WAL file(s) added, 0 removed, 0 recycled; write=4.561 s, sync=0.098 s, total=4.799 s; sync files=31, longest=0.062 s, average=0.004 s; distance=206 kB, estimate=206 kB; lsn=0/2D36310, redo lsn=0/2D362A0

[vabene1111]

sadly the performance of the DRF serializers is not optimal, especially for such a large nested model. I know that it is slow but to be honest never saw it being this slow on decent specs (as yours seem to be).

In the long run the only good optimization is writing the serializing logic by hand but so far I do not have the capacity to do so.

[DaveWestbury]

New user here with similar issue. Approximately 5-6s. I think if an indicator (spinner or something) could be placed on the save button to indicate the data is being saved it would alleviate this. Currently there is nothing to indicate anything is happening. I ended up clicking it a few times. Big fan.

[vabene1111]

this has been implemented for the new version. Also I feel like the timing generally is a lot faster there so going to close this for now.