I'm curius about your experiances with ImageGen with large amount of images in single folder. I have several installations with <1000 images in single folder and all work fast. Latest one has 30.000, only couple thousand resized so cached folder has only 3000 images, but server takes over 2 seconds to return an image.
I guess something else is the problem, but still, I'm curius if somebody serves this amount of images and how smooth it works.
Ideally you wouldn't have so many images in a single folder but the overhead of getting the correct file from a large listing (and rather large xml file) shouldn't be dramatic and such folder sizes have been used before.
There is, however, a potential bug in 2.5.7. I'd be curious if you are using 2.5.7 and if going back to 2.5.2 changes anything. It would be very helpful for me to know if someone else is experiencing the same problem as reported here: http://our.umbraco.org/projects/website-utilities/imagegen/imagegen-bugs/27938-Performance-problem. It might also be a workaround for you (remember to delete the 'cached' folders when installing a different version of ImageGen, and then wait for the initial cache to be populated before taking timing measurements).
Additionally, you can use client-side caching to speed things up for your visitors as well. That's available in ImageGen Professional using the 'class' feature. It's all explained in the PDF docs.
I've now reverted to 2.5.2.17053, emptied the Cached folder, and the mean request time has dropped to 54ms (the Cached folder is obviously smaller until more requests rebuild it).
Doug, if you want more details, or to try things out (this is on a staging site, so I have freedom to experiment ;-) then ping me; I appreciate it could be environment-specific.
Any news on a fix for this Doug? I've got another site that I think is suffering from this, but also needs at least v2.5.3 because of the CMYK JPG fix.
Does 2.5.3 also have the slow-down? If so, that will certainly limit the amount of changes between 2.5.2 and 2.5.3 to be reviewed. Looking at all the changes between 2.5.2 and 2.5.7, it isn't clear where the sluggishness is coming from, even with the profiler running. So more clues would be helpful. Or perhaps 2.5.3 is still okay?
I don't have a binary of 2.5.3 around to try (it's not in the Archived files section), but do have 2.5.4.27302, which seems much better (although it will take a while for the Cached folders to grow again).
If you can send me a 2.5.3 binary, I'll happily give that a go...
30.000 images in single folder?
I'm curius about your experiances with ImageGen with large amount of images in single folder. I have several installations with <1000 images in single folder and all work fast. Latest one has 30.000, only couple thousand resized so cached folder has only 3000 images, but server takes over 2 seconds to return an image.
I guess something else is the problem, but still, I'm curius if somebody serves this amount of images and how smooth it works.
Hi,
Ideally you wouldn't have so many images in a single folder but the overhead of getting the correct file from a large listing (and rather large xml file) shouldn't be dramatic and such folder sizes have been used before.
There is, however, a potential bug in 2.5.7. I'd be curious if you are using 2.5.7 and if going back to 2.5.2 changes anything. It would be very helpful for me to know if someone else is experiencing the same problem as reported here: http://our.umbraco.org/projects/website-utilities/imagegen/imagegen-bugs/27938-Performance-problem. It might also be a workaround for you (remember to delete the 'cached' folders when installing a different version of ImageGen, and then wait for the initial cache to be populated before taking timing measurements).
Additionally, you can use client-side caching to speed things up for your visitors as well. That's available in ImageGen Professional using the 'class' feature. It's all explained in the PDF docs.
Let us know what you find out.
cheers,
doug.
Doug,
I might be seeing the same problem, in 2.5.7.27945 (non-Pro);
I haven't tried reverting to an older version yet, but am happy to try that if you wish.
Phil
I've now reverted to 2.5.2.17053, emptied the Cached folder, and the mean request time has dropped to 54ms (the Cached folder is obviously smaller until more requests rebuild it).
Phil
@Phil, it does sound as though one of my 'optimisations' has gone desperately wrong :(
Thanks for confirming it, though, I appreciate that.
cheers,
doug.
Doug, if you want more details, or to try things out (this is on a staging site, so I have freedom to experiment ;-) then ping me; I appreciate it could be environment-specific.
@Phil, thanks, that's really helpful.
cheers,
doug.
Here is my report...
I was using version 2.5.7.2794.
First I deleted cached folder and tested again - no change, maybe only slightly faster on empty cached folder
Then I downgraded to 2.5.2 (only copied DLL over) and deleted cache again - back to normal.
So it seems there is a bug for sure.
P.S: This issue forced me to investigate client side caching and it is really amazing feature. Website flies once cached localy.
Any news on a fix for this Doug? I've got another site that I think is suffering from this, but also needs at least v2.5.3 because of the CMYK JPG fix.
Phil
Hi, Phil,
Does 2.5.3 also have the slow-down? If so, that will certainly limit the amount of changes between 2.5.2 and 2.5.3 to be reviewed. Looking at all the changes between 2.5.2 and 2.5.7, it isn't clear where the sluggishness is coming from, even with the profiler running. So more clues would be helpful. Or perhaps 2.5.3 is still okay?
cheers,
doug.
I don't have a binary of 2.5.3 around to try (it's not in the Archived files section), but do have 2.5.4.27302, which seems much better (although it will take a while for the Cached folders to grow again).
If you can send me a 2.5.3 binary, I'll happily give that a go...
phil
is working on a reply...