[performance] typed media calls making database queries
i've been profiling my website today and have seen a lot of these type of entries:
<ExecuteScalarWithRetry>b__0 ExecuteAction ExecuteScalar GetIdForKey GetIdForKey TypedMedia TypedMedia ConvertSourceToObject get_Value GetValue GetPropertyValue Execute ExecutePageHierarchy ExecutePageHierarchy Render RenderViewResultAsString Execute LoadPartialViewMacro renderMacro RenderMacro Execute ExecutePageHierarchy ExecutePageHierarchy Render
DECLARE @0 nvarchar(40) = N'73de290c-3375-4a09-94f1-5811542af6bd',
@1 nvarchar(40) = N'b796f64c-1f99-4ffb-b886-4bf4bc011a9c',
@2 nvarchar(40) = N'92849b1e-3904-4713-9356-f646f87c25f4';
SELECT id FROM umbracoNode WHERE uniqueId=@0 AND (nodeObjectType=@1 OR nodeObjectType=@2)
it appears to be a lookup for the integer ID of a media item, given its GUID, this i can tell by executing the sql query and also the GetIdForKey method is being called.
these db calls are really slowing things down so i'm wondering why this is necessary at all? why can't the GUID be used directly to lookup media, since it seems that the GUID is stored inside the examine index anyway?
maybe i'm misunderstanding why this happens but if anybody could explain why this is happening and/or how to avoid this or optimise, that would be great.
I believe that it doesn't query Examine by GUID because it wouldn't be able to cache that result properly - the cache invalidation is all based on integer IDs. So you'd have to query Examine for every call to TypedMedia(guid). Overall, it's better to have one SQL query and one Examine query the first time each media item is requested, and then be able to retrieve it from cache after that.
Having said that, it would be much quicker to do one database query to get a complete GUID-to-ID mapping for all media, then only make additional queries for cache misses. For content, a complete GUID-to-ID mapping is populated from the XML cache, but that doesn't help for media.
There's actually some unused code to populate a complete mapping from the database, presumably from testing whether the database or the XML cache was the fastest way to handle the content mapping. Unfortunately it's internal to Umbraco.Core, so you can't just call it from your own code.
[performance] typed media calls making database queries
i've been profiling my website today and have seen a lot of these type of entries:
it appears to be a lookup for the integer ID of a media item, given its GUID, this i can tell by executing the sql query and also the GetIdForKey method is being called. these db calls are really slowing things down so i'm wondering why this is necessary at all? why can't the GUID be used directly to lookup media, since it seems that the GUID is stored inside the examine index anyway?
maybe i'm misunderstanding why this happens but if anybody could explain why this is happening and/or how to avoid this or optimise, that would be great.
thanks, Simon
anybody familiar with the umbraco core that can shed some light on this??
thanks,
Simon
Hi Simon, did you ever get a resolution to this ? I am having the same issue
I believe that it doesn't query Examine by GUID because it wouldn't be able to cache that result properly - the cache invalidation is all based on integer IDs. So you'd have to query Examine for every call to
TypedMedia(guid). Overall, it's better to have one SQL query and one Examine query the first time each media item is requested, and then be able to retrieve it from cache after that.Having said that, it would be much quicker to do one database query to get a complete GUID-to-ID mapping for all media, then only make additional queries for cache misses. For content, a complete GUID-to-ID mapping is populated from the XML cache, but that doesn't help for media.
There's actually some unused code to populate a complete mapping from the database, presumably from testing whether the database or the XML cache was the fastest way to handle the content mapping. Unfortunately it's internal to Umbraco.Core, so you can't just call it from your own code.
is working on a reply...