starred/flyimg

Fork 0

mirror of https://github.com/flyimg/flyimg.git synced 2026-04-25 09:45:50 +03:00

[GH-ISSUE #495] With many flyimg docker replicas, does it make sense to share the /tmp directory ? #183

New issue

Closed

opened 2026-02-25 22:34:33 +03:00 by kerem · 6 comments

kerem commented

2026-02-25 22:34:33 +03:00

Owner

Originally created by @francescor on GitHub (Sep 9, 2024).
Original GitHub issue: https://github.com/flyimg/flyimg/issues/495

Originally assigned to: @sadok-f on GitHub.

We have been using successfully flyimg in a Traefik/Docker swarm setup with 2+ replicas (thanks!)

So far we did not use S3 (we'll start now) and to easy the load we've so far been sharing the /tmp directory between replicas: the idea was that the job of one container can be somehow recycled by the other container (I guess at least the 'download' of the original...)

This is the relevant part of the stack.yml file

...
    volumes:
      - /efs-directory/data/flyimg/tmp:/var/www/html/var/tmp
    environment:
      MAGICK_TMPDIR: /var/www/html/var/tmp      #mapped to filesystem
      MAGICK_THREAD_LIMIT: 8
      # Set maximum amount of memory map in bytes to allocate for the pixel cache. When this limit is exceeded, the image pixels are cached to disk (see MAGICK_DISK_LIMIT).
      MAGICK_MAP_LIMIT: '512MB'
      # Set maximum amount of memory in megabytes to allocate for the pixel cache from the heap. When this limit is exceeded, the image pixels are cached to memory-mapped disk (see MAGICK_MAP_LIMIT).
      MAGICK_MEMORY_LIMIT: '1024MB'
      MAGICK_WIDTH_LIMIT: '100MP'
      MAGICK_HEIGHT_LIMIT: '100MP'

btw: that shared dir ended up with over 100.000 files and over 50G, so I guess it's really too much

Now that we start using S3, does it make sense to still share that /tmp directory? (we'll enable the cron to empty it for sure now)

Originally created by @francescor on GitHub (Sep 9, 2024). Original GitHub issue: https://github.com/flyimg/flyimg/issues/495 Originally assigned to: @sadok-f on GitHub. We have been using successfully flyimg in a Traefik/Docker swarm setup with 2+ replicas (thanks!) So far we did not use S3 (we'll start now) and to easy the load we've so far been sharing the `/tmp` directory between replicas: the idea was that the job of one container can be somehow recycled by the other container (I guess at least the 'download' of the original...) This is the relevant part of the stack.yml file ``` ... volumes: - /efs-directory/data/flyimg/tmp:/var/www/html/var/tmp environment: MAGICK_TMPDIR: /var/www/html/var/tmp #mapped to filesystem MAGICK_THREAD_LIMIT: 8 # Set maximum amount of memory map in bytes to allocate for the pixel cache. When this limit is exceeded, the image pixels are cached to disk (see MAGICK_DISK_LIMIT). MAGICK_MAP_LIMIT: '512MB' # Set maximum amount of memory in megabytes to allocate for the pixel cache from the heap. When this limit is exceeded, the image pixels are cached to memory-mapped disk (see MAGICK_MAP_LIMIT). MAGICK_MEMORY_LIMIT: '1024MB' MAGICK_WIDTH_LIMIT: '100MP' MAGICK_HEIGHT_LIMIT: '100MP' ``` btw: that shared dir ended up with over 100.000 files and over 50G, so I guess it's really too much Now that we start using S3, does it make sense to still share that `/tmp` directory? (we'll enable the cron to empty it for sure now)

kerem

2026-02-25 22:34:33 +03:00

closed this issue
added the
question
label

kerem commented

2026-02-25 22:34:33 +03:00

Author

Owner

@sadok-f commented on GitHub (Sep 9, 2024):

@francescor that's a good question, when you enable S3 storage, only the generated images that will be served in the response will be stored there, the /tmp folder contains the original downloaded images plus the images that need multiple processing iterations.
for better performance I think it'll be good to keep sharing the /tmp folder between containers and setup the corn job to clean it up regularly.

@sadok-f commented on GitHub (Sep 9, 2024): @francescor that's a good question, when you enable S3 storage, only the generated images that will be served in the response will be stored there, the `/tmp` folder contains the original downloaded images plus the images that need multiple processing iterations. for better performance I think it'll be good to keep sharing the `/tmp` folder between containers and setup the corn job to clean it up regularly.

kerem commented

2026-02-25 22:34:33 +03:00

Author

Owner

@francescor commented on GitHub (Sep 9, 2024):

so, imagine I have two containers: A, B

I am curious of the scenario

When for the very first call for an image link (e.g. https://demo.flyimg.io/upload/o_auto,w_2500,h_2500/https%3A%2F%2Fs3-eu-west-1.amazonaws.com%2Fstatic.opencity.opencontent.it%2Fvar%2Fmasullas%2Fstorage%2Fimages%2F3330-2-ita-IT%2FHomepage_header_logo.png ) container A will

populate /tmp (saving there the original) then
elaborate it
save the resulting image in S3
serve the image

did I get it right?

When the same request arrive to the same container A what steps above will be skipped?

Now, when the same request arrives (for the first time) to the other container B (with no shared /tmp with container A) what will happen?

@francescor commented on GitHub (Sep 9, 2024): so, imagine I have two containers: A, B I am curious of the scenario When for the very first call for an image link (e.g. https://demo.flyimg.io/upload/o_auto,w_2500,h_2500/https%3A%2F%2Fs3-eu-west-1.amazonaws.com%2Fstatic.opencity.opencontent.it%2Fvar%2Fmasullas%2Fstorage%2Fimages%2F3330-2-ita-IT%2FHomepage_header_logo.png ) container A will 1. populate /tmp (saving there the original) then 1. elaborate it 1. save the resulting image in S3 1. serve the image did I get it right? When the same request arrive to the same container A what steps above will be skipped? Now, when the same request arrives (for the first time) to the other container B (with no shared /tmp with container A) what will happen?

kerem commented

2026-02-25 22:34:33 +03:00

Author

Owner

@sadok-f commented on GitHub (Sep 10, 2024):

The /tmp folder is used only to download the original image (if not there, or to force refresh with rf_1 option).

if you're using the same bucket for both containers, Flyimg will check if the generated image is already there (in your case in the S3 bucket), if so then serve it, otherwise it regenerates it again.

@sadok-f commented on GitHub (Sep 10, 2024): The `/tmp` folder is used only to download the original image (if not there, or to force refresh with `rf_1` option). if you're using the same bucket for both containers, Flyimg will check if the generated image is already there (in your case in the S3 bucket), if so then serve it, otherwise it regenerates it again.

kerem commented

2026-02-25 22:34:33 +03:00

Author

Owner

@sadok-f commented on GitHub (Sep 26, 2024):

Hi @francescor
did you get your answer to your question? can we close this issue?
Thanks!

@sadok-f commented on GitHub (Sep 26, 2024): Hi @francescor did you get your answer to your question? can we close this issue? Thanks!

kerem commented

2026-02-25 22:34:33 +03:00

Author

Owner

@francescor commented on GitHub (Sep 26, 2024):

We still have to go into production with the new setup (I need two step from my colleague which is pretty busy).

@francescor commented on GitHub (Sep 26, 2024): We still have to go into production with the new setup (I need two step from my colleague which is pretty busy).

kerem commented

2026-02-25 22:34:33 +03:00

Author

Owner

@francescor commented on GitHub (Oct 18, 2024):

did you get your answer to your question? can we close this issue?

yes, please

thank you

@francescor commented on GitHub (Oct 18, 2024): > did you get your answer to your question? can we close this issue? yes, please thank you

kerem referenced this issue

2026-02-25 22:35:06 +03:00

[PR #183] [MERGED] issue-#176: Update CodeClimate Test Reporter ID #176 #325

kerem referenced this issue

2026-03-15 15:43:38 +03:00

[PR #183] [MERGED] issue-#176: Update CodeClimate Test Reporter ID #176 #931