BrightcoveVideo::saveImage slow with S3FS

Hi,

I've looked into the issue, by setting up and using a local MinIO server (s3 compatible storage) and configured s3fs to push the files there.
Based on my test, saving the image to the s3 storage was done in 2ms for a newly uploaded video.

As I see the issue is with either the s3 storage, or the s3fs contrib module.
The Brightcove module is just using the 'file.repository' service to write the image data, in other words it propagates the task to core/s3fs.

Thanks, @yce for responding back, I've updated the issue.

Adjusting priority:

Major>Normal as issue does not appear to cause site failure only slowdown.

Normal>Minor in support of the Maintainer community ref: #3463640: Contact Material+ (formerly Srijan Technologies) about Contribution Best Practices →

Thanks, @Cmlara for updating the priority.

We have done the workaround by increasing the timeout, so I am happy with either "Normal" or "Minor".
When this was raised initially with Brightcove, our Videos as part of the creation process were timing out, sometimes taking 3-4 minutes.

Looking at initial images:
425 calls to saveImage() 23.22 seconds is 54.635ms per call.
228 calls to createFileName in 23.19 seconds is 101ms per call. That is a fair bit higher (and apparently from a different request).

createFilename timing:
Drupal Cache Bin Latency (s3fs 3.x uses the Default cache bin unless patched otherwise), SQL Database Latency, and is Ignore Metadata Cache enabled (never enable this in production) are what should impact that method performance the most.

The images to not provide enough details to opine further than that.

Timeouts: I'll have to defer to Brightcove on how do they handle multi-run tasks to ensure they do not timeout

Thanks, Its actually one request breakdown -

Under saveImage(), there are 425 calls, out of those 425, createFileName() took most of the time with 228 calls under this.

We are using default cache bin, and have not ignored metadata cache. So thats good.

For any database latency, i will do further analysis and see if i co-relate this.

Under saveImage(), there are 425 calls, out of those 425, createFileName() took most of the time with 228 calls under this.

That does change the interpretation of the timings.

Rest of my previous post will still hold true regarding what has the highest impacts on s3fs operations.

Setting postponed as there is nothing for maintainers to do untill further information is provided.

No information provided in over 2 weeks, closing as can not reproduce.