[Bug]: Missing Deferred Thumbnail Cache about pimcore HOT 12 CLOSED

We encounter the same problem using S3 and/or Azure Blob Storage. This essentially makes Documents almost unusable as they render extremly slow, especially with a lot of images with source sets.

This is very bad, as we have tons of assets in cloud storage and this makes it almost unusable for websites

from pimcore.

@solverat it seems you're having a thumbnail configuration which isn't supported by \Pimcore\Model\Asset\Image\Thumbnail\Config::getEstimatedDimensions() that's why it fallbacks to readDimensionsFromFile().

It's about this section here:

Can you confirm that?

One thing I'm wondering ... you're saying that even when readDimensionsFromFile() get's called, so the thumbnail get's generated, that the dimensions are not going into the cache - this I can't confirm, see also here:

I just debugged this, and it get's written to the cache.

So I think the main issue is that getEstimatedDimensions() is not able to calculate the dimensions of the thumbnail and therefore it's falling back to readDimensionsFromFile().

from pimcore.

In this case, I'm afraid the only thing you can do is to use disableWidthHeightAttributes when calling getHtml().

But still it would be good if you could share if it is really the case that dimensions are not written to cache when readDimensionsFromFile() get's called, because I'm not able to reproduce this.

Thanks

from pimcore.

@solverat any update? 😊

from pimcore.

@brusch it doesn't seem to me that saving the dimensions in the cache is the problem. I see entries in the assets_image_thumbnail_cache table that also look plausible. It seems to me that these entries are not being used?

Unfortunately I haven't had time to look at the flow in as much detail as @solverat , but the behavior seems to be the same for us.

We use thumbnails with transformations such as "Cover" or "ScaleByWidth".
Thumbnails and originals are on an Azure blob storage and the application runs in Kubernetes with HPA and separate pods for frontend (website) and Pimcore (admin), if this info is helpful

from pimcore.

@brusch we don't have any special thumbnail configuration (just default configs, created in backend).

The issue starts indeed here:

It never reaches the addThumbnailFileToCache, because $pathReference['storagePath'] is not set. And it is not set, because the thumbnail hasn't been created yet.

It's important that you're using some media queries to generate some deferred thumbnails URLs in the frontend output, because they are the issue here:

They never get rendered (Until the browser requests the image) but the dimensions will be calculated over and over again without caching it, because the Thumbnail itself hasn't been requested.

Yes, we currently disabled all the calculation by using the disableWidthHeightAttributes, but that's not a proper solution.

from pimcore.

I can confirm the findings of @solverat . The problem occurs when a thumbnail has not yet been created, which is often the case in combination with media queries/src-sets, as rarely all sizes have already been retrieved.
We have a worker for the command messenger:consume pimcore_image_optimize running, which reduces the problem. However, in our case we also have well over 100k images, so the worker can never generate thumbnails for all sizes

from pimcore.

Unfortunately I'm still not able to reproduce the issue using the latest 11.1 branch ...

Even if getEstimatedDimensions() is not returning a result here:

and the fallback readDimensionsFromFile() is getting called here:

it generated the thumbnail file *ONCE by calling getPathReference() here:

and then the thumbnail is added to the cache:

from pimcore.

So basically, yes, it's not ideal that the thumbnail file is getting generated, but it happens just once per file and not again and again.

Verified this by commenting the following line:

To ensure readDimensionsFromFile() is getting called.

from pimcore.

I could imagine that #16529 fixes your issue as well, maybe you can give it a try 😉
Thanks for your feedback.

from pimcore.

@brusch, you're right, and I also found the issue.

First I also was not able to reproduce it anymore, but because today is my lucky day, I just saw something our FE-Dev implemented differently:

Before

With Performance Issues

{% set image = pimcore_image('image_desktop') %}
{% if image is not empty %}
    {{ image.thumbnail('content_image').html|raw }}
{% endif %}

After

Without Performance Issues

{% set image = pimcore_image('image_desktop', {thumbnail: 'content_image'}) %}
{% if image is not empty %}
    {{ image.thumbnail('content_image').html|raw }}
{% endif %}

… and they further changed it later on, which is just the right way to do it:

{% if image.isEmpty == false %}
  {# ... #}
{% endif %}

Trace to the issue:

• image = pimcore_image('image_desktop') does not pass any thumbnail config (issue 1)
• if image is not empty forces a string cast, which triggers the render method in the image editable, which then renders the HTML structure without any thumbnail definition (issue 2)

So I don't think it's a real pimcore bug, even if it's a "good to know" thing! :)

Thanks for your efforts and tenacity (I hope that this will also help others).

from pimcore.

@solverat you're welcome 😊 Thanks for sharing your findings!

from pimcore.