How can I speed up the first request after a deployment?
I'm working on a site that I have added to a Visual Studio solution (as a Web Site project) and I have a Web Application project configured with uSiteBuilder that copies assemblies and masterpages to the website after build.
I run the website using the Visual Studio 2010 built-in developer webserver. Each time I build the web application project and then refresh (either a front-end page or some section in the back-end) it takes 25 or 30 seconds. It's just not a workable solution for me.
Do you guys have the same problem, and if so, how do you solve it?
First request takes a lot of time because application start is being done on first request. During application start uSiteBuilder is doing its synchronization - it goes through all document types, properties, templates, macros etc... and updates if there is anything to be updated. So that's why it could be slow.
In the next version of uSiteBuilder we will add option to web.config so that uSiteBuilder synchronization could be temporarily turned off and that could be solution for you (of course, if you make changes to document types or add new templates you'd have to turn this option back on so that uSiteBuilder can do its synchronization).
Until than, are you maybe doing builds just to copy files? For example, if you make changes to css or javascript files, you still do build just to get files copied? If that's the case, instead of doing builds everytime, you can create some batch file that will be similar to post build batch but instead of coping dlls you should just copy .master, .ascx, css files, javascript files etc... so those files that do not cause website restart. That way you'll reduce number of application restarts during development.
Correct, build to copy, even just stylesheet changes. Takes too long.
I have switched to working with just one Web Application project, that includes only the folders that I work on (css, DocumentTypes, images, macroScripts, masterpages, scripts, usercontrols, xslt). I then install Umbraco into that folder and run it directly from Visual Studio. Works the same for uSiteBuilder after a build, but this way I don't have to rebuild for changes in CSS, JavaScript or HTML.
I don't knwo why there is so much guidance on using a separate location for the Umbraco install with IIS, it seems to work just fine when running from Visual Studio and it's much easier to have one project. No xcopy or robocopy and easier to debug too.
Your solution works but there are many drawbacks of having Umbraco install in the same place where your code is. It's always better to keep your source code separated from actual place where it should be deployed and where it should be running. That's not related to Umbraco but to software development in general.
What you can also do, in order to copy only those css, javascripts, .master etc... without building application is that you can create batch file as I mentioned earlier and than create an External Tool item in Visual Studio (Tools/External Tools) that will just execute your batch file. You can also assign shortcut to that item so instead of hiting F6 to build solution, you can hit, for example, Ctrl+F6 to just do copy files without building solution.
It's always better to keep your source code separated from actual place where it should be deployed and where it should be running. That's not related to Umbraco but to software development in general.
Actually, that is A) not true at all and B) only related to Umbraco.
A) I'm not working on the server, I'm developing locally. So that is where the source code should be. Having to always copy after editing too see it running, no matter what clever XCOPY build events one can come up with has never been necessary in my 6 years as an ASP.NET developer. I'm quite surprised to see this advice that one should always copy source before running it. By all means, work that way if you want, but I'm not going to do that.
B) Umbraco is a strange system in that it wants to be a CMS for content but also wants to be the editor for code. That is the main reason I believe why people are saying you should copy files over to the folder that Umbraco is installed in. So it is actually 100% related to Umbraco. Umbraco seems to be developer not with a team in mind, but rather with a single developer in mind, possibly even with the expectation that this single developer works on the live server.
So to conclude my reply, I'm very surprised by your last post, because I am convinced that it's the exact other way around. I'm interested to hear your opinions.
A) I didn't say that source should be copied but project output. When developing for Umbraco, you are actually developing extension to Umbraco so it makes no sense that you include whole Umbraco into your source for many different reasons - just think what would you include into your source code if you would develop something for SharePoint. That's not related to uSiteBuilder anyway so I prefer not to go into that discussion. You can use uSiteBuilder no matter if you copy files or not so do it as you feel right.
B) I agree with most of your statement here. uSiteBuilder is made exactly because of that - to help you build Umbraco websites by team of developers, reduce browser based development and thus make deployments easier. That has nothing to do with copying files or not.
A) The example of SharePoint is very clarifying, thanks! I have only done 1 small project with that, but I remember that the Visual Studio project type was customized to deploy assets and build artefacts on build to a local instance of SharePoint.
B) Umbraco is hardly the only CMS with this problem:
I have some experience with a different CMS, Kentico, same amount of letters in the same, same last two letters in the name and same problems with deployment of CMS objects :-). Where Umbraco has Courier, Kentico has an import/export facility as well as a synchronization option (in the more expensive SKUs). I had started a project myself on Codeplex to see if I could deploy document types from an assembly, based purely on classes decorated with attributes. (The project is called Kryptonite but since I don't use Kentico anymore, i doubt I will finish it :-).
I know that there is a similar OSS project for EPIServer, and that there is a commercial product for Sitecore that integrates deeply with Visual Studio and stores meta data about CMS objects for deployment. So it seems the problem set is the same for many of the major ASP.NET CMSes out there.
So now you will probably understand why I like to discuss this type of code and workflow :-)
uSiteBuilder seems to like a great start, but because you can't (yet) create all types of CMS objects, it's not possible to use it exclusively as a solution to team development. We are looking at Courier, once we start using that, we may not need uSiteBuilder anymore.
- - -
Anyway, in our current setup we have a separate Class Library project that references uSiteBuilder, only to deploy templates, doctypes and membertypes. We have a Web Site project using IIS that references the library. In the web site we have /masterpages, /usercontrols, /css etc under version control, but nothing else. A tema member must install Umbraco (using Web Platform Installer for example) before he can run the site.
Wit this setup, we can do quick template development because we don't have to build the library for changes in CSS, JavaScript, HTML etc. Our template masterpages also don't inherit from the classes in the Library, we just use them to create CMS objects. No need yet for the uSiteBuilder API.
I think that Courier and uSiteBuilder are not excluding each other. uSiteBuilder is there to help you reduce browser based development and make deployments easier. Courier is there to help with content migration. Fact that Courier can also be used to migrate document types, templates etc... is just a workaround that may work for somebody but it's certainly not the right way to do it unless you have no other choice. Not to mention that Courier is not OSS and if you base your development on it, it becomes crucial part of your project which makes your Umbraco project not OSS.
Eventhough uSiteBuilder currently do not support building a website completely in Visual Studio (mostly due to Umbraco restrictions) it is certainly going in that direction and we are planning to get to a point where you can have your whole website implemented without opening browser (except for testing of course). That will be much easier to accomplish once Umbraco 5 gets out.
"Fact that Courier can also be used to migrate document types, templates etc... is just a workaround that may work for somebody but it's certainly not the right way to do it unless you have no other choice"
I don't know about that, to me it seems like a developer tool just as well as an editor tool. With Courier 2 you can selectively add CMS objects like doctypes to a Subversion repository, doesn't seem like a workaround to me.
And as it is right now, as long as uSiteBuilder doesn't support all objects, then we are indeed in a situation where we have no other choice.
As a new Umbraco developer (for 3 weeks now) it really makes me wonder how people have been building Umbraco sites for so long. Did they just work directly on the live server, or did they just recreate every object in multiple instances?
"In the next version of uSiteBuilder we will add option to web.config so that uSiteBuilder synchronization could be temporarily turned off and that could be solution for you (of course, if you make changes to document types or add new templates you'd have to turn this option back on so that uSiteBuilder can do its synchronization)."
I don't believe this was implemented in the newest version (v.1.2)? When can we expect it? it's really needed.
How can I speed up the first request after a deployment?
I'm working on a site that I have added to a Visual Studio solution (as a Web Site project) and I have a Web Application project configured with uSiteBuilder that copies assemblies and masterpages to the website after build.
I run the website using the Visual Studio 2010 built-in developer webserver. Each time I build the web application project and then refresh (either a front-end page or some section in the back-end) it takes 25 or 30 seconds. It's just not a workable solution for me.
Do you guys have the same problem, and if so, how do you solve it?
Hi Michiel,
First request takes a lot of time because application start is being done on first request. During application start uSiteBuilder is doing its synchronization - it goes through all document types, properties, templates, macros etc... and updates if there is anything to be updated. So that's why it could be slow.
In the next version of uSiteBuilder we will add option to web.config so that uSiteBuilder synchronization could be temporarily turned off and that could be solution for you (of course, if you make changes to document types or add new templates you'd have to turn this option back on so that uSiteBuilder can do its synchronization).
Until than, are you maybe doing builds just to copy files? For example, if you make changes to css or javascript files, you still do build just to get files copied? If that's the case, instead of doing builds everytime, you can create some batch file that will be similar to post build batch but instead of coping dlls you should just copy .master, .ascx, css files, javascript files etc... so those files that do not cause website restart. That way you'll reduce number of application restarts during development.
Correct, build to copy, even just stylesheet changes. Takes too long.
I have switched to working with just one Web Application project, that includes only the folders that I work on (css, DocumentTypes, images, macroScripts, masterpages, scripts, usercontrols, xslt). I then install Umbraco into that folder and run it directly from Visual Studio. Works the same for uSiteBuilder after a build, but this way I don't have to rebuild for changes in CSS, JavaScript or HTML.
I don't knwo why there is so much guidance on using a separate location for the Umbraco install with IIS, it seems to work just fine when running from Visual Studio and it's much easier to have one project. No xcopy or robocopy and easier to debug too.
Your solution works but there are many drawbacks of having Umbraco install in the same place where your code is. It's always better to keep your source code separated from actual place where it should be deployed and where it should be running. That's not related to Umbraco but to software development in general.
What you can also do, in order to copy only those css, javascripts, .master etc... without building application is that you can create batch file as I mentioned earlier and than create an External Tool item in Visual Studio (Tools/External Tools) that will just execute your batch file. You can also assign shortcut to that item so instead of hiting F6 to build solution, you can hit, for example, Ctrl+F6 to just do copy files without building solution.
It's always better to keep your source code separated from actual place where it should be deployed and where it should be running. That's not related to Umbraco but to software development in general.
Actually, that is A) not true at all and B) only related to Umbraco.
A) I'm not working on the server, I'm developing locally. So that is where the source code should be. Having to always copy after editing too see it running, no matter what clever XCOPY build events one can come up with has never been necessary in my 6 years as an ASP.NET developer. I'm quite surprised to see this advice that one should always copy source before running it. By all means, work that way if you want, but I'm not going to do that.
B) Umbraco is a strange system in that it wants to be a CMS for content but also wants to be the editor for code. That is the main reason I believe why people are saying you should copy files over to the folder that Umbraco is installed in. So it is actually 100% related to Umbraco. Umbraco seems to be developer not with a team in mind, but rather with a single developer in mind, possibly even with the expectation that this single developer works on the live server.
So to conclude my reply, I'm very surprised by your last post, because I am convinced that it's the exact other way around. I'm interested to hear your opinions.
A) I didn't say that source should be copied but project output. When developing for Umbraco, you are actually developing extension to Umbraco so it makes no sense that you include whole Umbraco into your source for many different reasons - just think what would you include into your source code if you would develop something for SharePoint. That's not related to uSiteBuilder anyway so I prefer not to go into that discussion. You can use uSiteBuilder no matter if you copy files or not so do it as you feel right.
B) I agree with most of your statement here. uSiteBuilder is made exactly because of that - to help you build Umbraco websites by team of developers, reduce browser based development and thus make deployments easier. That has nothing to do with copying files or not.
A) The example of SharePoint is very clarifying, thanks! I have only done 1 small project with that, but I remember that the Visual Studio project type was customized to deploy assets and build artefacts on build to a local instance of SharePoint.
B) Umbraco is hardly the only CMS with this problem:
I have some experience with a different CMS, Kentico, same amount of letters in the same, same last two letters in the name and same problems with deployment of CMS objects :-). Where Umbraco has Courier, Kentico has an import/export facility as well as a synchronization option (in the more expensive SKUs). I had started a project myself on Codeplex to see if I could deploy document types from an assembly, based purely on classes decorated with attributes. (The project is called Kryptonite but since I don't use Kentico anymore, i doubt I will finish it :-).
I know that there is a similar OSS project for EPIServer, and that there is a commercial product for Sitecore that integrates deeply with Visual Studio and stores meta data about CMS objects for deployment. So it seems the problem set is the same for many of the major ASP.NET CMSes out there.
So now you will probably understand why I like to discuss this type of code and workflow :-)
uSiteBuilder seems to like a great start, but because you can't (yet) create all types of CMS objects, it's not possible to use it exclusively as a solution to team development. We are looking at Courier, once we start using that, we may not need uSiteBuilder anymore.
- - -
Anyway, in our current setup we have a separate Class Library project that references uSiteBuilder, only to deploy templates, doctypes and membertypes. We have a Web Site project using IIS that references the library. In the web site we have /masterpages, /usercontrols, /css etc under version control, but nothing else. A tema member must install Umbraco (using Web Platform Installer for example) before he can run the site.
Wit this setup, we can do quick template development because we don't have to build the library for changes in CSS, JavaScript, HTML etc. Our template masterpages also don't inherit from the classes in the Library, we just use them to create CMS objects. No need yet for the uSiteBuilder API.
I think that Courier and uSiteBuilder are not excluding each other. uSiteBuilder is there to help you reduce browser based development and make deployments easier. Courier is there to help with content migration. Fact that Courier can also be used to migrate document types, templates etc... is just a workaround that may work for somebody but it's certainly not the right way to do it unless you have no other choice. Not to mention that Courier is not OSS and if you base your development on it, it becomes crucial part of your project which makes your Umbraco project not OSS.
Eventhough uSiteBuilder currently do not support building a website completely in Visual Studio (mostly due to Umbraco restrictions) it is certainly going in that direction and we are planning to get to a point where you can have your whole website implemented without opening browser (except for testing of course). That will be much easier to accomplish once Umbraco 5 gets out.
"Fact that Courier can also be used to migrate document types, templates etc... is just a workaround that may work for somebody but it's certainly not the right way to do it unless you have no other choice"
I don't know about that, to me it seems like a developer tool just as well as an editor tool. With Courier 2 you can selectively add CMS objects like doctypes to a Subversion repository, doesn't seem like a workaround to me.
And as it is right now, as long as uSiteBuilder doesn't support all objects, then we are indeed in a situation where we have no other choice.
As a new Umbraco developer (for 3 weeks now) it really makes me wonder how people have been building Umbraco sites for so long. Did they just work directly on the live server, or did they just recreate every object in multiple instances?
I don't believe this was implemented in the newest version (v.1.2)? When can we expect it? it's really needed.
Stefan, you are right. This is not added to version 1.2. We'll add it to version 1.3.
is working on a reply...