Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature request: update for imagor and thumbor #1

Open
liudongmiao opened this issue Oct 9, 2024 · 2 comments
Open

feature request: update for imagor and thumbor #1

liudongmiao opened this issue Oct 9, 2024 · 2 comments

Comments

@liudongmiao
Copy link

  1. thumbor docker support THUMBOR_NUM_PROCESSES
    https://github.com/MinimalCompact/thumbor?tab=readme-ov-file#quick-start
    docker run ... -e THUMBOR_NUM_PROCESSES=xxx or so

  2. imagor docker support avif speed now
    -vips-avif-speed 9 or so

And in my test with wrk, it seems imagor and imgproxy has the same performance, and multi-process thumbor (python) bench +10% than multi-thread of go. (wrk requires lua script to avoid url cache)

@DarthSim
Copy link
Member

DarthSim commented Oct 9, 2024

Hey @liudongmiao!

https://github.com/MinimalCompact/thumbor

Oh, my bad. I saw their Docker Hub but the Thumbor version there is pretty outdated. I didn't realize they publish images on GH Packages now.

thumbor docker support THUMBOR_NUM_PROCESSES
and multi-process thumbor (python) bench +10% than multi-thread of go

I'm aware of Thumbor's multi-processing mode, but I intentionally didn't use it. Multi-processing is indeed more performant than multi-threading in tasks like this. However, it's not necessary to have a multi-processing mode in the tool itself. Having a Docker image, you can easily run multiple replicas of a server and load-balance requests between them. So it would be not fair to use multi-processing for Thumbor but not for imgproxy and imagor. So I decided to not use it at all.

imagor docker support avif speed now

Oh, neat

And in my test with work

Can I take a look?

@liudongmiao
Copy link
Author

@DarthSim After switching the dataset from our single picture to DIV2K dataset, the result changed:

  1. png to webp without fit-in, imgproxy > thumbor > imagor (less than 10%)
  2. png to webp with fit-in 1024, imgproxy >> thumbor >> imagor (almost 20+%)
    I'll look into imagor to find the difference, why the same libvips cause so much difference in fit-in cases.

The wrk script is like this:

local tid = 1

function setup(thread)
    thread:set("id", tid)
    tid = tid + 1
end

function init(args)
   counter = 0
end

function request()
    counter = counter + 1
    if string.find(wrk.path, "%%3F") then
        path = wrk.path .. "%26c=" .. counter .. "%26t=" .. id
    else
        path = wrk.path .. "%3Fc=" .. counter .. "%26t=" .. id
    end
    path = string.gsub(path, "%%d", (counter % 100) + 801)
    return wrk.format(nil, path)
end
# for imgproxy, %d would be replaced in the lua script
./wrk -t 12 -c 48 -d 60s -s counter.lua 'http://127.0.0.1:8000/unsafe/rs:fit:1024:1024/f:webp/q:80/plain/http://10.110.7.14/mic/DIV2K_valid_HR/0%d.png' 

# for imagor and thumbor, %d would be replaced in the lua script
./wrk -t 12 -c 48 -d 60s -s counter.lua 'http://127.0.0.1:8001/unsafe/fit-in/1024x1024/filters:format(webp):quality(80)/http://nginx/DIV2K_valid_HR/0%d.png' 

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants