You're getting all the media items regardless of whether they are used within the site (and accessing media is a DB intensive process, hence why caching was introduced), loading the URLs based on DB information (despite the fact they are read out of an in memory cache file) and all the members?!
I've seen plenty of sites I'd consider small which have a few dozen media files and a few thousand members, which would result in huge memory consumption, and n+1 database calls...
There's also the question of cache turnout, because there's so much being added into the cache you're going to run out of allocated memory and items will get removed, possibly items that actually should be cached. The point of the cache is to ensure that the items that are used as available on demand.
I'm building a webshop with a lot of images per product. Each image is called with library.GetMedia. If the media items are not cached the first user visiting this page has to wait until all media image url's are loaded from the database. I want to prevent this with this packages which caches all media items on application_start using a different thread. In my situation all media items are used in the site so I wanted to have them all cached. The same goes for NiceUrl. I use library.NiceUr a lot so it's easy if all links are cached from the beginning.
You might be right about which items should be cached, but in my situation I need everything to be cached (and our server has enough memory for this) and that's what I'm using this package for.
Why?
Why would you want to use this?
You're getting all the media items regardless of whether they are used within the site (and accessing media is a DB intensive process, hence why caching was introduced), loading the URLs based on DB information (despite the fact they are read out of an in memory cache file) and all the members?!
I've seen plenty of sites I'd consider small which have a few dozen media files and a few thousand members, which would result in huge memory consumption, and n+1 database calls...
There's also the question of cache turnout, because there's so much being added into the cache you're going to run out of allocated memory and items will get removed, possibly items that actually should be cached.
The point of the cache is to ensure that the items that are used as available on demand.
I needed this package in the following situation:
I'm building a webshop with a lot of images per product. Each image is called with library.GetMedia. If the media items are not cached the first user visiting this page has to wait until all media image url's are loaded from the database. I want to prevent this with this packages which caches all media items on application_start using a different thread. In my situation all media items are used in the site so I wanted to have them all cached. The same goes for NiceUrl. I use library.NiceUr a lot so it's easy if all links are cached from the beginning.
You might be right about which items should be cached, but in my situation I need everything to be cached (and our server has enough memory for this) and that's what I'm using this package for.
Jeroen
Isn't better to create page with all products images and then create request to it when app starts?
Hi Petr,
That's a nice idea! I'm currently busy, but the project is open for collaboration so you could help if you want to :).
Jeroen
is working on a reply...