We are using ImageGen Pro 2.5.7 for a large Danish book webshop.
The "product images" folder had ~45000 images, which was not the best I agree :)
ImageGen couldn't manage such a big folder =>
- We had constantly 100% CPU used
- The index.xml file could be as large as 40GB !! and sometimes it droped down to 30Mb .. the size changed a bit randomly it seemed.
We tried to delete the Cached folder, change version of ImageGen (and delete again the Cached folder), IISReset etc.. it didn't change anything.
We do not use "nocache".
The obvious solution we used is to split the large product images folder into 100 separates folder of 450 images each.
Now the performance, CPU and index files are good again :)
I'm writing this post here so people having the same problem could benefice from this experience and maybe it could help Douglas to find the reason of the big index file.
You're exactly right that massive folders of images will make ImageGen slow. Much better to split into folders of modest size.
The problem ultimately stems from the design of ImageGen 2 and the index.xml file. The architecture will be changing for v3 (this summer) to make it performant no matter how many images are in a folder.
We have the exact same problem on another site : when we loaded the image from an external site (with ImageGenPro), it all goes to the same folder (/data/Cached/nameofexternalsite/...) and the index.xml is growing so much that the site is down with 100% CPU trying to read/write the huge index.xml file...
Do you have a roadmap for imagegen 3 ? or a solution for external sites ?
Sorry to pull up an old thread but we're having this problem using a Windows server accessing Media from an Azure blog storage. The site behaves fine until we get loads of duplicate entries in the index.xml file, it grows to about 2-4Gb and then everything grinds to a halt.
As Doug didn't manage to get v3 out, did anyone find an answer to this issue?
Imagegen problem with large image folder
Hello,
We are using ImageGen Pro 2.5.7 for a large Danish book webshop.
The "product images" folder had ~45000 images, which was not the best I agree :)
ImageGen couldn't manage such a big folder =>
- We had constantly 100% CPU used
- The index.xml file could be as large as 40GB !! and sometimes it droped down to 30Mb .. the size changed a bit randomly it seemed.
We tried to delete the Cached folder, change version of ImageGen (and delete again the Cached folder), IISReset etc.. it didn't change anything.
We do not use "nocache".
The obvious solution we used is to split the large product images folder into 100 separates folder of 450 images each.
Now the performance, CPU and index files are good again :)
I'm writing this post here so people having the same problem could benefice from this experience and maybe it could help Douglas to find the reason of the big index file.
Cheers,
Fabrice
Thanks, Fabrice!
You're exactly right that massive folders of images will make ImageGen slow. Much better to split into folders of modest size.
The problem ultimately stems from the design of ImageGen 2 and the index.xml file. The architecture will be changing for v3 (this summer) to make it performant no matter how many images are in a folder.
cheers,
doug.
Hello,
We have the exact same problem on another site : when we loaded the image from an external site (with ImageGenPro), it all goes to the same folder (/data/Cached/nameofexternalsite/...) and the index.xml is growing so much that the site is down with 100% CPU trying to read/write the huge index.xml file...
Do you have a roadmap for imagegen 3 ? or a solution for external sites ?
Thank you very much
We have the same issue! The summer is over.... We are eager to know the release date :).
Do you have some updates?
Sorry to pull up an old thread but we're having this problem using a Windows server accessing Media from an Azure blog storage. The site behaves fine until we get loads of duplicate entries in the index.xml file, it grows to about 2-4Gb and then everything grinds to a halt.
As Doug didn't manage to get v3 out, did anyone find an answer to this issue?
Thanks,
Alex
is working on a reply...