Slow performance for context with a large number of tables
Posted: Wed 07 Dec 2016 15:43
We recently converted our ORM models from the old Telerik the ones we generated using the depreciated Telerik add-on for Visual Studio to fresh ones using the Devart Telerik Data Access Model item using Entity Developer. Our original DbContext file had these lines at the top, the difference being the addition of a MetadataContainer variable, I'm not using if Telerik had generated this or a developer added it
Many of the constructors also used metadataContainer instead of metadataSource
When were regenerated the models it did not include the metadataContainer variable and the constructors used metadataSource. When we deployed our API using the new settings we experienced very slow performance when calling the API, in the realm of 1-3 seconds. For reference this context has around 80 tables and a couple of the tables have 60+ columns.
When we were trying to determine what was causing this issue and changed the DbContext file back to how it was, adding the metadataContainer and using it in constructors the performance greatly increased back to under 150ms.
We've changed the template file to use this in our domains now, but is there a way to avoid having to do this in the future for our other contexts that still haven't been converted and is this an issue with contexts that have a large number of tables?
Code: Select all
private static BackendConfiguration backend = GetBackendConfiguration();
private static MetadataSource metadataSource = new OracleProdDbContextMetadataSource();
private static readonly MetadataContainer metadataContainer = metadataSource.GetModel();
private static string connectionString = @"OracleProfile";When were regenerated the models it did not include the metadataContainer variable and the constructors used metadataSource. When we deployed our API using the new settings we experienced very slow performance when calling the API, in the realm of 1-3 seconds. For reference this context has around 80 tables and a couple of the tables have 60+ columns.
When we were trying to determine what was causing this issue and changed the DbContext file back to how it was, adding the metadataContainer and using it in constructors the performance greatly increased back to under 150ms.
We've changed the template file to use this in our domains now, but is there a way to avoid having to do this in the future for our other contexts that still haven't been converted and is this an issue with contexts that have a large number of tables?