0

I'm trying to root cause the issue with slow speed upon sign in in my EF6 web app hosted in azure. With all the research I've done I still don't quite understand why my app is behaving the way it is.

When I first deploy the app, and attempt to sign in, it's slow, this I understand why, and it's acceptable. Subsequent sign-ins and calls are relatively quick. What I don't understand is why if I don't interact with the application for maybe 5 minutes (even though my Azure Web App has Always On set to Enabled and is a Standard pricing tier Web App) the next login will be back down to taking 20+ seconds.

I don't quite understand what "First Run" means when anyone says it in regards to Entity being slow. Does it only mean, "the first time the web app is accessed by ANYONE", or does it mean something like, "When the dbContext is instantiated by ONE SPECIFIC client for the first time, that is THEIR specific first run, and their instance of the app/dbcontext whatever is now warmed up and ready"

The latter doesn't seem to make sense, because I can sign in on one machine, and move to another machine and it will be relatively quick as well.

Dylan Fenton
  • 1
  • 1
  • "First Run" would refer to the first time an EF query is run after the Entity Framework assemblies are loaded in to an app domain. – Bradley Uffner Jan 27 '16 at 15:31

2 Answers2

0

"First time" means first dbContext use (query) after the application starts. But when app is iddle for some time, app pool is restarted and next time you enter the site it will start again. That's why EF takes time when there is no activity for some time.

Have a look at this post about app pool restart in azure

Community
  • 1
  • 1
tede24
  • 2,304
  • 11
  • 14
  • Thanks, but the Always On feature they added is supposed to prevent the app pool from recycling according to Microsoft, anyway, who knows if they're telling the truth. – Dylan Fenton Jan 27 '16 at 15:36
  • I'm just explaining why it takes time to start after idle. I don't know if you need to use Always On or not, you should go deeper in that and decide what's best for you app. – tede24 Jan 27 '16 at 15:40
  • Here you have another post about auto start http://stackoverflow.com/questions/14238569/force-application-start-on-azure-web-role, you should research about this concept (maybe that post or another) to speed up your login – tede24 Jan 27 '16 at 15:45
0

"First Run" would refer to the first time an EF query is run after the Entity Framework assemblies are loaded in to an app domain.

EF is a fairly large set of assemblies and they take a bit of time to load initially. On the first query they will also do a lot of work verifying the model. A lot of this time can be reduced by Pre-caching the views for the model (MSDN). For databases with a lot of mapped tables and stored procs this can be a quite a long time. I've had projects that could take up to 3 minutes to start up. Precaching reduced that to about 10 seconds. It does add quite a bit of complexity to managing schema changes though.

Before the Entity Framework can execute a query or save changes to the data source, it must generate a set of mapping views to access the database. These mapping views are a set of Entity SQL statement that represent the database in an abstract way, and are part of the metadata which is cached per application domain. If you create multiple instances of the same context in the same application domain, they will reuse mapping views from the cached metadata rather than regenerating them. Because mapping view generation is a significant part of the overall cost of executing the first query, the Entity Framework enables you to pre-generate mapping views and include them in the compiled project.

Bradley Uffner
  • 16,641
  • 3
  • 39
  • 76