DD4T.Web.Binaries.BinaryFileManager has functionality which resizes image. I'm concerned about performance of this functionality.

It works at request time, and it doesn't create image file if requested file has already exists. But DD4T has to check whether requested file is existing or not every time image file is requested. That means if a page contains 100 image files and 100 user requests the page, DD4T checks file existence 10000 times. This is the reason that I'm concerned about performance.

Has DD4T caused performance problem on actual environment?

1 Answer 1


Its not clear if your performance concerns are related to the request time resizing of images, or in general to the way DD4T manages binaries.

On the performance of request time image resizing, yes it is an additional processing step, but it is only done once per image/size, not on every request for that image/size. You have to balance this performance hit, with for example the alternative of resizing the image to all required sizes at publish time. This will slow down publishing, and also build a dependency to require content to be republished if you want to alter the dimensions of images used in your web design (or add a new format). You have to decide what is more important.

On the performance of DD4T for binaries in general, checking the FS is a pre-requisite of any web application which serves binaries from the FS, so thats not a DD4T specific concern. What DD4T does do differently is check the last published date of the binary to ensure that the version on the FS is up to date. These last published dates are stored in the DD4T cache, so I don't think the overhead is that great, but if you have concerns, perhaps load test it to put your mind at rest and if its not sufficient introduce your own check/cache strategy.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.