1

we're running EntityFramework (6.1.3) Code-First with about 40 migrations on a small database (490 MB) on SQL Azure.

While extending our release process with a check to call Database.CompatibleWithModel to verify if the database is up to date, I've found that our test instance got rather slow: this call will take up to 2 minutes to complete. On our production environment and locally this is less than a second!

I've run a SQL profiler job locally and found only 3 statements that get fired on the the database:

  1. Does the database exist?
  2. How many migrations are in the database?
  3. What is the migrationId and model of the last migration?

When I run these statements on the slow environment it completes within a second, just like on production. This indicates that the database is not an issue.

Does anyone have an idea were to search for the reason of the slow performance? Does EF calculate the hash locally on runtime and then checks that against the model in the database? Can I find out how long it takes to hash?

I've checked the settings on the Azure Database to check against the CompatibilityLevel of the database, after finding a post that the EDMX editor is slow with the new cardinality estimator, but this setting seems to have no effect.

Rob Bos
  • 1,320
  • 1
  • 10
  • 25
  • Did you solve this? I have a similar issue:http://stackoverflow.com/questions/42403789/azure-mobile-app-slow-linq-to-sql-but-fast-query – François Feb 23 '17 at 13:52
  • Hi François, alas, no solution found. – Rob Bos Feb 23 '17 at 14:30
  • Do you understand when it's called though? I thought it was only on startup but realized sometimes it's called when not expected. Unless my webapi restarts without any actions from me. – François Feb 23 '17 at 14:37
  • We check it ourselves after pushing a new build in production, just to check if the database was updated properly. I think this is automatically called on instantiation of the DbContext? – Rob Bos Feb 23 '17 at 14:40
  • Are you sure? I do "new context()" all over the place... – François Feb 23 '17 at 14:44
  • We've got a simple call in an action that does nothing more than: `var compatible = new EfDbContext().DatabaseCompatibleWithModel();` and it takes 1.5 minutes consistently today. So we do not see resets of the duration after e.g. a SQL reset after 5 minutes, like you found in your other questions – Rob Bos Mar 07 '17 at 10:53

0 Answers0