Hi Steve

Can't see your attached picture.

Anyways you could add a setting to your OWN initialization modules to not to load when certain key is in the appsettings, to improve your start-up. BUT, the idea of initialization modules IS that those are executed before the application starts accepting requests and render content - and other code can trust that correct initialization has been done. So in that sense you might just create other issues in your app.

If your startup takes long, you should investigate your OWN modules, what takes there so long and if there is something you could improve.

https://cl.ly/b0717e86270e

Link to the screenshot that I tried to post.

Hi Steve,

But that screenshot shows thta your initialization modules are executed in 24 seconds. So something else is adding to your startup time to return the content, one thing is the view compilation(s). Traditional HDD vs SSD makes a difference in startup (it can be half of the time on SSD what it is on HDD).

I would use diagnostics tools to identify what is going on, where the additional time is spent. I suppose this is your sites start page loading? Are the next request to the start page fast after the initial request? If so, do you have some cache / service initialization done when the page is loaded, like building a huge main navigation, etc what is not done initialization module but when something is requested the first time. Anyways debugging/analyzing the code paths will indicate where the most time is spent -> so have a look at those.

How is the initialization timings in your test/qa/prod environments?

Hi Steve,

One thing you could look for is your log4net logging strategy.  I was working on a project for which most of our logger level were set to Info or Warn (EPiServerLog.config) and they were producing a lot of entries into our logs on startup.

On DEV, we changed the level to Off and we saw a huge loading time difference.

Ex:

1. Never start site using debugging mode if you don't need. You can attach debugger later if needed. Start without debugging.
2. Have db locally. First request is done without any cache and doing that over slow network hurts a lot.
3. SSD with NVME
4. Check initialization modules and optimize on time (24s are pretty much. Don't know why the ServiceApi takes so long to init)
5. Logging at error level if not needed
6. Use prefix.io to check what db calls are done at startup. Are you loading a very large menu that is deep? Might want to do that async? 

We have found the same issue with Find.Commerce being extremely slow.

For custom init modules/code we have added an appsetting that we can change on develop that we use with custom code to disable the longer running custom startup items when needed but ofcourse with epi built in items its not great to just go switching them off.