When looking at performance on our server, we found that the index.xml file was being constantly re-written for images that are being requested from external sties. Windows 2008's Resource Monitor is telling me that depending on traffic, we're hitting 100,000,000 b/Min write rate on the index.xml file (the read rate is 0). Because of the caching issue, ImageGen is not serving up the cached image anyway, so we're taking a massive hit writing this index.xml file, when we don't need it.
Is there anything we can do about this? It looks that even if we specify a nocache attribute for an image request, ImageGen will still write the index.xml file...
There are a few minor bugs that we're working on that could cause problems with a corrupt index.xml file and orphaned cached images requiring images to be re-created with subsequent requests. There is no reliable workaround for these occurances, though some things can make the situation worse or more likely to occur. Remote images is one of the factors that is more likely to encounter the issue and deleting the offending cached folder from time to time is the only short-term solution.
Writing to the index.xml file is common. Every time there is a new cached image created the index.xml file is written to to record the specific parameters and the filename that contains the cached image. When a request is made for an image that is already cached the index.xml file does not need to be written as no new information needs to be saved. UNLESS you use the nocache=true parameter, in which case you will ALWAYS create a new cached image and write its details to the index.xml file. You should not use nocache=true except in very rare (usually debugging) cases.
The index.xml file is only read at application pool startup. From then on, ImageGen looks up information from memory for speed. As a new request comes in, the memory and then the index.xml file is updated. Thus, there is no need to read the index.xml file except when the memory is empty (at appPool startup).
We're working on ImageGen 3 beta for CodeGarden, but it may only be an 'alpha' version as it hasn't gotten as much testing as we'd like and there are a few issues yet to resolve. We are committed to solving the issues and will release alpha, beta, and production versions as soon as we can.
Cached index.xml file being constantly re-written
Hi,
This is related to a caching bug I raised previously: http://our.umbraco.org/projects/imagegen/imagegen-bugs/8382-ImageGen-intermittently-not-displaying-images---a-new-caching-bug-in-221
When looking at performance on our server, we found that the index.xml file was being constantly re-written for images that are being requested from external sties. Windows 2008's Resource Monitor is telling me that depending on traffic, we're hitting 100,000,000 b/Min write rate on the index.xml file (the read rate is 0). Because of the caching issue, ImageGen is not serving up the cached image anyway, so we're taking a massive hit writing this index.xml file, when we don't need it.
Is there anything we can do about this? It looks that even if we specify a nocache attribute for an image request, ImageGen will still write the index.xml file...
Thanks
Matt
Have you installed the fix for the caching bug? See the project page's instructions near the bottom.
Thanks for reporting your problem, Matt.
There are a few minor bugs that we're working on that could cause problems with a corrupt index.xml file and orphaned cached images requiring images to be re-created with subsequent requests. There is no reliable workaround for these occurances, though some things can make the situation worse or more likely to occur. Remote images is one of the factors that is more likely to encounter the issue and deleting the offending cached folder from time to time is the only short-term solution.
Writing to the index.xml file is common. Every time there is a new cached image created the index.xml file is written to to record the specific parameters and the filename that contains the cached image. When a request is made for an image that is already cached the index.xml file does not need to be written as no new information needs to be saved. UNLESS you use the nocache=true parameter, in which case you will ALWAYS create a new cached image and write its details to the index.xml file. You should not use nocache=true except in very rare (usually debugging) cases.
The index.xml file is only read at application pool startup. From then on, ImageGen looks up information from memory for speed. As a new request comes in, the memory and then the index.xml file is updated. Thus, there is no need to read the index.xml file except when the memory is empty (at appPool startup).
We're working on ImageGen 3 beta for CodeGarden, but it may only be an 'alpha' version as it hasn't gotten as much testing as we'd like and there are a few issues yet to resolve. We are committed to solving the issues and will release alpha, beta, and production versions as soon as we can.
cheers,
doug.
is working on a reply...