I have an API template that returns an array of URLs for a large amount of images, among other pieces of information. The original images are large in size, so for the initial preview images that are shown on the page I have it also generate a specific resized image.
foreach($graphicstemplate->files() as $file) {
if ($file->extension() == 'png' || $file->extension() == 'jpg') {
$templateimage = $file->url();
$templatethumb = $file->resize(320, null, 80)->url();
}
elseif ($file->type() == 'document' || $file->extension() == 'eps') {
$templatefile = $file->url();
$templatefiletype = $file->extension();
}
}
This is working great, except for when other pages get updated. Kirbyās cache seems to wipe out the thumbnails that were generated (even though the updates were not related to this section at all), creating a long delay until the they are regenerated.
Is there anyway of preventing the cache from wiping these out upon other page changes?
Thumbs and the cache are two different stories. The cache is wiped every time a page is updated, thatās correct. This is necessary because Kirby canāt possibly know what pages are affected by a page update. The thumbs, however, are generated in the thumbs folder. And luckily the new Kirby version 2.5.1 only deletes thumbs if necessary, highly increasing thumb performance.
Iām on Kirby 2.5.1. Still, when other pages are updated, it takes forever for the template to rebuild this unrelated page. It appears that itās still going through and processing the images, causing the long delay. Subsequent calls to the template are very fast, until again, another unrelated page is updated. So I guess what Iām asking is, is there away to keep the cache from marking this particular template needing updates unless it is updated? Or a way to check if new items were added to the page and conditionally run the above code?
Well, the question is if the thumbs are really regenerated (which shouldnāt be the case, because thumbs are usually only generated once so they donāt have to be regenerated), of if it is anything else that slows down page rendering if the page is not cached. Why do you think the thumbs are regenerated?
If I comment out $templatethumb = $file->resize(320, null, 80)->url(); it loads instantly (albeit without the thumbnails). Looking at the creation dates on the files, it looks like what is actually happening is that when the cache is marked for updating and the template is called, it is running the resize method, but not overwriting the thumbs. Maybe is there a way to check if an image already has a thumb, and then generate one accordingly?
1 Like
Well, as I said, I donāt know what is happening there, maybe it is somehow related to this issue, although there is no talk of the cache being involved. How many images are we talking about?
The thumb constructor only generates a new thumb if the thumb does not exist yet. So there must be something else causing the delay. We are currently investigating the other issue.
Currently itās about 200 images. The originals are around 3480x2880 and the thumbs are 320x240. Thatās why Iām baffled, because like you said, I thought that it only generated them if they donāt exist yetā¦ though if I keep that line of code in, it takes a very long time if Kirbyās cache is reset/refreshed.
I tried both
$templatethumb = thumb($file, array('width' => 320, 'quality' => 80))->url();
and
$templatethumb = $file->resize(320, null, 80)->url();
ā¦both get the same result. Again, if I remove that single line of code, the rest executes instantly.
Unfortunately, I canāt reproduce this issue at all, it makes hardly any perceivable difference if the cache is cleared or not in a fresh Starterkit installation (testing with approx. 150 images in a project page from Unsplash). While it takes quite a while to create the first set, page load is fast on subsequent page loads unless I delete the thumbs manually. But thumbs are definitely not deleted if the cache is cleared.
Yeah, itās so strange. I can see that the thumbs are there, and they arenāt being re-written, but itās almost as if it processes them again before it checks if theyāre their or not.
Do you by chance experience this on a windows machine? I get the exact same behaviour and have since the beginning on Windows boxes. Even if I run a VM using an exact image of my production server, makes no difference. Iāve just got the habit of using image manipulation only in production environment, development is just too painful otherwise.
Interesting idea, @RushmerIO, what is your local Windows setup?
Currently running a Vagrant VM, Ubuntu 16.04 64bit, php7.1, caddy 0.10.4. Exact same setup on production server minus the VM does not display this behavior. Itās not a Caddy issue either, I can duplicate the issue with Nginx as a server or as a proxy for Apache, as well as stand-alone Apache. Iāve had the issue with earlier versions of Ubuntu and Xxamp as well. All I can figure is that the windows machine is the only constant variable.
Because of it, Iāve wrapped any image manipulation I do within a function and check for IP.
Simply put, if Localā¦ output URL, if notā¦ output manipulation.
I did a quick test on a Windows machine (using Mamp directly on the box, no VM stuff) and I can confirm that there is a clearly perceivable delay when loading a page with many thumbs (154 images, cache disabled, as compared to performance on my Mac), but the delay is definitely much shorter than when the thumbs have to be generated for the first time. This actually results in a big difference in loading time between a cached page and the page being reloaded after the cache was cleared.
I never thought about thatā¦ this is actually running on a Windows machine. Let me run it on my Mac and see if thereās a difference. Still note, that itās incredibly fast unless that single line of code is run after the cache is cleared.
@texnixe, I see what youāre saying with 154 images, with 12 there is no perceivable difference, the response from the server is almost identical to the first run(generating thumbnails) or second+ run. Leads me to believe the overhead isnāt related to file count.
Definitely related to it running on the Windows server. Just ran it on the Mac and after the first time the thumbs are generated, itās very fast, even after disabling Kirbyās cache.
@RushmerIO Interesting that this also affects a VM running on Windows. But it is clearly beyond me to even try to look into this.
@texnixe, I tried to narrow it down some more but I canāt. Funny thing is I also canāt get Kirby to play nicely with IM on a windows box, I wanted to test that as well.
Iām still wondering if and how this issue relates to this one: Image (Resize, Crop, ...) doesnāt use previous generated files (no Windows involved)