Switching concurrency from cpucount to 1 increated performance. Looking for an explanation

[wardpeet]

What are you trying to achieve?

At Gatsy we are playing with sharp's concurrency and queue'ing. It seems limitting sharp to 1 cpu (thread?) makes image generation faster for us. I've read https://sharp.pixelplumbing.com/api-utility#concurrency but still unsure what's the cause of it is. In my head concurrency should make things faster if you have multiple transforms for 1 image.

Anything we should be aware of when setting it to 1? Is this expected behaviour? How can we optimize sharp even more?

Have you searched for similar questions?
#2322

Are you able to provide a minimal, standalone code sample that demonstrates this question?
gatsbyjs/gatsby#28575

Are you able to provide a sample image that helps explain the question?

With concurrency = cpucount, queue 1 at a time

success Generating image thumbnails - 311.836s - 532/532 1.71/s
info Done building in 317.3029042 sec

concurrency = 1, queue = cpucount

success Generating image thumbnails - 174.163s - 532/532 3.05/s
info Done building in 179.6475083 sec

Second site:

With concurrency = cpucount, queue 1 at a time

Generating image thumbnails - 436.176s

concurrency = 1, queue = cpucount

Generating image thumbnails - 259.491s

[lovell]

Hi, as you've seen, there are concurrency threads spawned to process each image, which can have an overhead - there's some discussion about re-using thread pools in libvips at libvips/libvips#1492

In Gatsby, am I right in thinking that the queue will look like the following?

[[in_1, out_1_1], [in_1, out_1_2], [in_1, out_1_3], [in_2, out_2_1] ...]

If so, and there are lots of JPEG inputs, then you might be experiencing a thread-safety limitation of libjpeg.

All libvips-spawned threads that operate on the same JPEG input image must share a mutex (i.e. block each other). Preventing the effects of this could be as simple as randomising the queue order, so adjacent items in the queue are more likely to refer to different input images.

[lovell]

Sorry, I missed a bit of the linked issue - why is Gatsby currently only queuing one image at a time? I would imagine the queue should always contain at least 4 items, the default value of UV_THREADPOOL_SIZE, to gain any kind of parallelism.

[vladar]

It is a jobs queue. Each job corresponds to a single input image but contains several image transformations: usually from 2 to 5.

So it is more like this:

[[in_1, out_1_1, out_1_2, out_1_3], [in_2, out_2_1, out_2_2,] ...]

[lovell]

Thanks, this suggests you are probably are seeing the effects of JPEG input mutexes.

The proposed increase in Gatsby's "queue concurrency" will also increase thread count, which then reduces the effects of any blocked threads as these will (mostly) no longer be on the critical path.

It would be interesting to compare the two approaches when using only non-JPEG inputs to see if there is any difference.

[lovell]

It looks like the linked issue at gatsbyjs/gatsby#28575 has been merged so will close this question as it appears the previous approach to queuing in Gatsby was affected by libjpeg input mutexes.

[wardpeet]

Yes, thanks @lovell for the advice! 🙏