November Happy Hour will be moved to Thursday December 5th.
November Happy Hour will be moved to Thursday December 5th.
It was ContentAreaRenderer.RenderContentAreaItems
.
It accepts a list of ContentAreaItem
. But the IContent
of these are already individually preloaded at that stage.
I haven't tested this myself, just curious what if you go 1 level up and override Render()
method?
@valdis: that doesn't make a difference.
Turns out the constructor of ContentAreaItem
is loading the content (from cache or DB). And this is called when accessing the ContentArea.Items
properties, which happens before reaching the methods I mentioned.
I think it would be nice if that constructor didn't preload the content item, just to check that it exists. Maybe the Items
enumerator could batch preload the core data (not the complete content data) before calling the constructors.
Working on a site with content areas with many content area items, I was profiling the site and database to improve the first load performance of the site.
I attempted to batch load all items when rendering each content area (in a
CustomContentAreaRenderer
, usingIContentLoader.GetItems
). But before even reaching my batch loading code, it turns out Episerver had already loaded each block individually and sequentially. Actually, for most of of the blocks it even called two stored procedures per content area item:netFindContentCoreDataByContentGuid
andnetContentDataLoad
.It would be really nice if Episerver could batch load all the blocks, when enumerating
ContentArea.Items
, instead of loading individually?Or Episerver could just batch preload
ContentAreaItem
(callingnetFindContentCoreDataByContentGuid
) when callingContentArea.Items
. Then the actual content could be batch loaded in aCustomContentAreaRenderer
.