We are having some performance issues with our umbraco web sites. Every time we do a deploy, or there is an automated upgrade on umbraco cloud, we are experiencing 20-30 seconds time to first byte for the first request to content of each template / document type. All subsequent requests to content of the same template / doctype are quick (60 ms-ish).
We believe have chased this down to be view compilation. In local visual studio we can see that when we hit content with a view that isn't compiled, it will start compiling and loading the DLLs like this:
'iisexpress.exe' (CLR v4.0.30319: /LM/W3SVC/2/ROOT-4-131611733419648059): Loaded 'C:\Users\(SomeUser)\AppData\Local\Temp\Temporary ASP.NET Files\vs\83b3c140\ca2d4bae\App_Web_header.cshtml.be8c2a3e.taaxpuxu.dll'.
This will happen for each partial called in the view, taking about 1 second for each view or partial view. So, this might take like 5-10 seconds locally depending on how many partials the view is using, translating into 20-30 seconds in umbraco cloud.
This is a horrible experience for the first users after a deploy, especially on low traffic sites, where it might take some time before everything has been hit.
Ideally we would like all views and partials to be compiled and loaded at startup, so that we have a controllable amount of time that the site is slow, and that it will be nice and quick once properly initialized.
We have read about pre-compiling views, and that's maybe what we need to do to solve this. However, we are using Umbraco Cloud with the recommended visual studio setup. In this setup, our views are in a Website project (Umbraco.Web) where we don't have a .csproj.
Does anyone have any experience with this, or some pointers to where we should start looking to proceed on this?
All I can say is that Umbraco.io is meant for small and medium-sized websites. You do not have many options for the hosting environment as Umbraco.io cloud takes care of your environment and compilation
Adding a .csproj file wouldn't have the result you are looking for.
You may want to add an additional environment, deploy to that, "warm" that environment up and then swap to the Live environment.
As well as that you can add a webhook to Post Deployment, I wouldn't take much to write a script that "warms up" the site on post-deployment.
You may also want to look at your web.config for an answer, something like the following may work:
I already created an azure function which fetches the sitemap and crawls all the pages and put it in a webhook. This kinda works.
I looked into your tip, and it looks promising. A bit of a pain that it has to statically refer to the urls, but it looks like this can be done in code as well? Not really sure where that would be put in an umbraco cloud website project though.
Thanks, I'll check this out. Seems like the first approach didn't work very well in umbraco cloud, all though it seemed to load all the views i requested at startup locally.
I see the article has some references to putting stuff in csproj though.
Precompiled views in umbraco cloud
Hi,
We are having some performance issues with our umbraco web sites. Every time we do a deploy, or there is an automated upgrade on umbraco cloud, we are experiencing 20-30 seconds time to first byte for the first request to content of each template / document type. All subsequent requests to content of the same template / doctype are quick (60 ms-ish).
We believe have chased this down to be view compilation. In local visual studio we can see that when we hit content with a view that isn't compiled, it will start compiling and loading the DLLs like this:
This will happen for each partial called in the view, taking about 1 second for each view or partial view. So, this might take like 5-10 seconds locally depending on how many partials the view is using, translating into 20-30 seconds in umbraco cloud.
This is a horrible experience for the first users after a deploy, especially on low traffic sites, where it might take some time before everything has been hit.
Ideally we would like all views and partials to be compiled and loaded at startup, so that we have a controllable amount of time that the site is slow, and that it will be nice and quick once properly initialized.
We have read about pre-compiling views, and that's maybe what we need to do to solve this. However, we are using Umbraco Cloud with the recommended visual studio setup. In this setup, our views are in a Website project (Umbraco.Web) where we don't have a .csproj.
Does anyone have any experience with this, or some pointers to where we should start looking to proceed on this?
All I can say is that Umbraco.io is meant for small and medium-sized websites. You do not have many options for the hosting environment as Umbraco.io cloud takes care of your environment and compilation
Adding a .csproj file wouldn't have the result you are looking for.
You may want to add an additional environment, deploy to that, "warm" that environment up and then swap to the Live environment.
As well as that you can add a webhook to Post Deployment, I wouldn't take much to write a script that "warms up" the site on post-deployment.
You may also want to look at your web.config for an answer, something like the following may work:
Thanks Mark.
I already created an azure function which fetches the sitemap and crawls all the pages and put it in a webhook. This kinda works.
I looked into your tip, and it looks promising. A bit of a pain that it has to statically refer to the urls, but it looks like this can be done in code as well? Not really sure where that would be put in an umbraco cloud website project though.
Hey Havard
I also found this article that may help:
https://stacktoheap.com/blog/2013/01/19/precompiling-razor-views-in-asp-dot-net-mvc-3/
It mentions the I one discussed as well as one that you can add to the App_Started event. It is a little old, but I think still relevant.
Let me know how you get on.
Thanks, I'll check this out. Seems like the first approach didn't work very well in umbraco cloud, all though it seemed to load all the views i requested at startup locally.
I see the article has some references to putting stuff in csproj though.
Yeah but if you read on, the solution that uses OnApplicationStarted might be better.
is working on a reply...