A few weeks ago I upgraded to umb 7.3.3 and the iis process memory consumption grew until the configured max memory (1gb) and the process recycled. This only took 15 minutes so our site was resetting every 15 minutes.
I increased the max memory to 2gb and it took about an hour hit that mark.
I ended up reverting back to umb 7.2.8 while I looked into the problem/memory dumps further.
I took some time but I was able to determine that ImageProcessor was loading every requested image into the memory cache.
Our site is an ecom site with over 60,000 product images. We aren't using ImageProcessor but it looks like with the latest upgrade ImageProcessor started intercepting every image request even if no processing was requested.
The older version of ImageProcessor doesn't do this.
As a fix I tested commenting out the LocalFileImageService entry in the security.config and the problem went away.
So I am wondering if GetCropUrl will still work if LocalFileImageService is disabled? I'm not using GetCropUrl right now but I may want to in the future.
Also, would this be considered a bug with ImageProcessing if it is processing images that don't explicitly request changes to the image?
Could you please raise ImageProcessor issues at the correct location. i.e The issue tracker at the Github repository. It's only by word of mouth that I saw this.
ImageProcessor does not load every image into the memory cache. It loads a reference to a cached image location for a sliding 10 minute window. You can see that easily in the source code.
I very much doubt that this is the cause of the issue since a single instance would only be around 250-300 bytes which would only be 14-20 MB memory wise.
Could you clarify how you are requesting/loading images? Do you have any further information, dumps, logs you could share? 60,000 isn't anywhere near the largest site running ImageProcessor (471k images is the largest I know of) and I've not heard any other reported issues. I would like to see if there is a leak introduced somewhere though.
Intercepting all images is not a bug. It was an additional feature that was designed to ensure all images within the site were optimized. It can only work when RAMMFAR is enabled. I am however switching the behaviour back to intercepting only images with querystring parameters as it's much easier for debugging.
Most people who have ImageProcessor installed in a website are actually using it so I'm wondering why you are not?.
GetCropUrl cannot possibly work without ImageProcessor, how would you expect the images to be resized otherwise?
James,
Yes, I will raise an issue at github about ImageProcessor. But the question was about more about Umbraco's integration with ImageProcessor so I don't see how this isn't an correct location.
I was asking if it was a bug because it seem like the design changed from the previous version that was used in umbraco and it seems like a waste to default to optimizing images that don't request it and may all ready be pre-optimized.
I'm not using ImageProcessor yet because it came with Umbraco and I just recently upgrade from Umbraco 4.x to 7.2.8 and didn't know about this service.
As to GetCropUrl I miss read what the remote.axd url structure was used for and wasn't sure if GetCropUrl would make requests based on that structure. But I see now that is used for processing images from other websites.
Thanks for raising the issue, there was lots of additional info in your report which I'm very grateful for.
The issue tracker is definitely the best place to lodge any ImageProcessor specific issues. (If it's the ImageCropper here is best) since I will then be able to see the issue and hopefully provide a fix/explanation.
I'll stick a link here to the additional issue on Github so people can follow. I've commented there and I think changing the FCN mode to Single will probably help.
Umbraco 7.2.8 Upgrade to 7.3.3 caused memory issues. Tracked down to upgrade of ImageProcessor
A few weeks ago I upgraded to umb 7.3.3 and the iis process memory consumption grew until the configured max memory (1gb) and the process recycled. This only took 15 minutes so our site was resetting every 15 minutes.
I increased the max memory to 2gb and it took about an hour hit that mark.
I ended up reverting back to umb 7.2.8 while I looked into the problem/memory dumps further.
I took some time but I was able to determine that ImageProcessor was loading every requested image into the memory cache.
Our site is an ecom site with over 60,000 product images. We aren't using ImageProcessor but it looks like with the latest upgrade ImageProcessor started intercepting every image request even if no processing was requested.
The older version of ImageProcessor doesn't do this.
As a fix I tested commenting out the LocalFileImageService entry in the security.config and the problem went away.
So I am wondering if GetCropUrl will still work if LocalFileImageService is disabled? I'm not using GetCropUrl right now but I may want to in the future.
Also, would this be considered a bug with ImageProcessing if it is processing images that don't explicitly request changes to the image?
Thanks, David
Hi David,
Could you please raise ImageProcessor issues at the correct location. i.e The issue tracker at the Github repository. It's only by word of mouth that I saw this.
ImageProcessor does not load every image into the memory cache. It loads a reference to a cached image location for a sliding 10 minute window. You can see that easily in the source code.
https://github.com/JimBobSquarePants/ImageProcessor/blob/ab01a422b2c8463ee7bbaa57fe158fe5bb89f321/src/ImageProcessor.Web/Caching/CacheIndexer.cs#L65
I very much doubt that this is the cause of the issue since a single instance would only be around 250-300 bytes which would only be 14-20 MB memory wise.
Could you clarify how you are requesting/loading images? Do you have any further information, dumps, logs you could share? 60,000 isn't anywhere near the largest site running ImageProcessor (471k images is the largest I know of) and I've not heard any other reported issues. I would like to see if there is a leak introduced somewhere though.
Intercepting all images is not a bug. It was an additional feature that was designed to ensure all images within the site were optimized. It can only work when RAMMFAR is enabled. I am however switching the behaviour back to intercepting only images with querystring parameters as it's much easier for debugging.
Most people who have ImageProcessor installed in a website are actually using it so I'm wondering why you are not?.
GetCropUrl cannot possibly work without ImageProcessor, how would you expect the images to be resized otherwise?
Regards
James
James, Yes, I will raise an issue at github about ImageProcessor. But the question was about more about Umbraco's integration with ImageProcessor so I don't see how this isn't an correct location.
I was asking if it was a bug because it seem like the design changed from the previous version that was used in umbraco and it seems like a waste to default to optimizing images that don't request it and may all ready be pre-optimized.
I'm not using ImageProcessor yet because it came with Umbraco and I just recently upgrade from Umbraco 4.x to 7.2.8 and didn't know about this service.
As to GetCropUrl I miss read what the remote.axd url structure was used for and wasn't sure if GetCropUrl would make requests based on that structure. But I see now that is used for processing images from other websites.
Thanks,
David
Hi David,
Thanks for raising the issue, there was lots of additional info in your report which I'm very grateful for.
The issue tracker is definitely the best place to lodge any ImageProcessor specific issues. (If it's the ImageCropper here is best) since I will then be able to see the issue and hopefully provide a fix/explanation.
I'll stick a link here to the additional issue on Github so people can follow. I've commented there and I think changing the FCN mode to Single will probably help.
Cheers
James
is working on a reply...