Slow Orchard Performance on Windows Azure - azure

I have a small Orchard website that I'm hosting on Windows Azure. This website is currently configured to use a FREE web site instance. I've noticed that the first time the site is accessed after a 20-30 minute period, it takes a while (>5 seconds) to load. After that initial load, I can revisit the site, and its fast. I suspect that the app pool is recycling fairly often as its a FREE Azure Web Site instance.
I need this site to load as fast as possible. I'm not opposed to using a different Azure option. I'm just not sure what I should be using.
1) Is there a way in my Orchard site's web.config file to set how often the app pool is recycled? I really need this site to be quick.
2) If I use a "SHARED" Web Site instance, will this get me past the recycling issue?
3) Or, do I need a "RESERVED" Web site instance.
My main goal here is to cost-effectively meet my goal of loading my web site quickly after it hasn't been accessed in a while. I'm just not sure what I can/should do.
Thank you!

I use a combination of the following for performance issues:
I enable Keep Alive module
I enable Warmup module and in Performance settings add my most visited pages
I manually set machine key inside web.config so that sessions last regardless of recycling - this could be an issue if there's not enough memory allocated for the web site inside the IIS
These steps are not related specifically to Azure, but rather to any kind of hosting. Especially when using Azure shared web site instances since they're nothing more than a shared hosting (unlike Azure cloud services)..

Azure web role can easily be made to be fast and avoid the appPool recycle issues, so consider that your plan B after trying all options with Azure websites.
I haven't tried with Azure websites, so it may or may not be possible there. Info is vague as to whether or not you can configure the idle timeout setting for a reserved instance. One thing you can try is to use the warm-up feature (dashboard -> performance). This should periodically load some pages, which would prevent idle timeout of the appPool. You might also try external services like pingdom.com or something similar that would periodically ping your site to prevent it from recycling.
If you end up switching to web roles, you will definitely be able to do this. The latest Orchard builds (v1.6+) set the appPool idle timeout to 0 (never timeout) by default. You will in general get a lot more control over performance and other configuration if you use web role rather than azure websites. The main drawback with this choice is you lose some of the deployment options, and deployments take a lot longer (they are still easy, they just take a while).

Related

Asp.NET Core 2.1 HostedService - keep running on Azure

We have a web application that is using the IHostedService.
There is an example of this here
And the method we employed is detailed here
The goal was to have an application that continually ran background tasks. So we could schedule in jobs that run automatically at set times. This application is separate from all our other applications, so it's not visited by our user base.
So we needed a way for this application to run all the time on Azure.
We tried to set up an App Service for the application on Azure, but it seems that the application does not continually run. Things seem to run locally ok, but on Azure, I have to stop and restart the service before it kicks in the IHostedService tasks.
Is there a way on Azure to keep the application alive and running?
Ok, so in the App Settings in Azure, there is a setting Always On this worked for us. :)
We also found out from Azure support, that if you are on the lowest tier in their offered packages, this is treated as a "Development" environment and will only have limited up-time. As a result, we could expect the application to go offline when we reached that limit.
We argued that there should have been something more obvious in the dashboard for us to know this.
Once we upgraded to a Standard tier, the application stayed online.
Also, if you are running a hosted service and it hits an unhandled exception, this stops the service. You need to make sure you are handling exceptions for this to work.

Azure Websites Memory Usage For Multiple Websites with same DLLs

We are moving a range of Cloud services Web Roles to Azure websites - currently running on App Service plan/pricing tier - Standard 1 medium.
The websites are all identical and at some point we will re-write out code base to be properly multi-tenanted. However we are currently hosting them as multiple websites on a single Azure web hosting plan.
In terms of memory usage will Azure share the identical Dlls e.g. all the Nuget packages/core application Dll? Or do we need enough memory to load a copy of each Dll per websites? Effectively I am hoping to share you can share common assemblies across AppPools.
I have seen mention of settings that MS was adding to IIS to support better density for shared hosting providers. I believe .Net 4.5 added support for interned Dll. Are there any settings etc that affect how Azure handles this situation? We are currently running at 94% memory consumption of our 3.5GB and wanted to understand whether we would need to scale up soon. I would hope Azure would be able to do something under the covers as obviously MS want to maximize density.
Each WebApp is isolated by the app-pool so if you have multiple copies of the same site, even if they are identical, they will all load their own copy of the assembly into memory.
There is also the security sandbox due to the multitenant nature of the service so interning will not work against that.
To monitor memory usage, you can look at the app service plan. Also useful is process explorer (WebApp>tools>process explorer)

Deploying and maintaining multiple copies of the same web application at different URLs on Azure

I'm currently investigating the possibility of my company using Azure.
Our current hosting situation that we run ourselves involves a separate site in IIS for each of our clients, each one having a virtual directory to the CMS we've built with ASP.Net web forms. We can update the contents of that virtual directory, which then provides the latest version of our CMS to all our clients at once.
I'm not looking to recreate that exact situation in Azure, but I am instead interested in figuring out how to create a single Web application in Visual Studio, publish that application to Azure in such a way that multiple sites (that I've specified) are created on Azure. Then I would like to be able to make changes to that application, and publish it again in a such a way that all the sites for it get updated all together, without requiring something be done manually per site/client.
The closest explanation I've found is this one:
http://www.wadewegner.com/2011/02/running-multiple-websites-in-a-windows-azure-web-role/
That gets me close, but what I don't understand is that when I publish this application to Azure, I still only see one application / URL available in the Azure management console. Shouldn't the extra "Site" node result in a different site being available when I publish it? Why doesn't it? Is there a completely separate way to accomplish this that I'm not using?
When you look at the management console you're seeing the web roles that you have deployed, not the sites that are part of that web role which is why you're only seeing one. As long as you've followed the instructions correctly, then yes, you do have two sites running. The catch is that you can only access the main site through that default URL. Presuming you have urls that look like customer1.mysite.com and customer2.mysite.com, you need to make sure you've set these as the host headers in the sub sites and then change your DNS so both of these domains point to URL you can see in the portal (e.g. mysite.cloudapp.net).
When considering a multi-tenant solution, ideally you should design your web-application as a single website that is capable of responding to multiple tenants (each of your customers), as opposed to creating a website/web-application for each one of them. This makes updates across the system manageable.
Your web-application can partition and identity different tenants based on several options such as part of the url (e.g myapp/tenant1 vs myapp/tenant2) or via a host header (e.g. tenant1.myapp.cloudapp.net vs tenant2.myapp.cloudapp.net)
HTH

How to publish dotnetnuke website to azure?

I am looking at migrating a dotnetnuke website to Azure. I need both staging and production versions of the site to be running.
I have looked at using Azure Websites, but at the moment there is no support for SSL on custom domains so this can't be used for the production website. I have migrated the staging site to an Azure Website and now have numerous options for publishing updates (ftp, git, using web matrix).
Due to the constraints of Azure Websites, I used the DNN Accelerator to create a cloud service for the production environment. This set up will allow me to have control over IIS and therefore manage SSL certificates (I think).
The problem I have with this is there does not seem to be any publishing options. The only way I can publish is by connecting to the Azure instance via RDP and then copying the website files onto the files system.
Are there any other ways of publishing? I have looked at converting the website to a WAP, but I believe this has implications when it comes to updating to new DNN versions.
You should never publish your application through RDP since these changes are non-persistent (meaning what you published might disappear after a hardware failure / ...). Adding new instances would also mean that these instances don't have the files you published before.
I suggest you start by looking at the DotNetNuke Azure Accelerator first. If this doesn't fit your needs you might always try to build something yourself, but if you want to say with a regular website and not a web application I wouldn't count on Visual Studio support. In that case you might want to look at creating a package from the command line and using startup scripts to add your website in IIS.
Sounds like you need to use a Start-up task to install the files in the correct place for a Web Role (Cloud Service) Smarx has a nice overview here, MSDN has a wealth of info too http://blog.smarx.com/posts/introduction-to-windows-azure-startup-tasks
Another option is IAAS for Azure with a persisted VM, more work mind you, Cloud Service would be the most efficient and correct solution...

App pool timeout for azure web sites

is there a way to set the timeout of an app pool of a web-site running under azure sites.
I have a site running there and it seems like it needs to spin up again when it has been idle for a while.
Since the relevant answer is in the comments it is easy to miss it. Currently Azure Web Apps support the Always On feature, that keeps your app in memory. It is available in Basic and upper tiers and you can configure it from the portal:
Resource_Group > Web App > Settings > Application settings
If you want to achieve the same effect in Free or Shared tiers you can create a webjob that will ping your website to keep it in memory. There are numerous blog posts how to achieve this 1, 2, etc.
Windows Azure Web Sites supports two modes, shared and Reserved.
In Shared mode, your web site process (w3wp) runs alongside other, sharing resources including CPU and memory. The runtime (that is Windows Azure Web Sites system) remove sites from memory after period of idleness – that is when your site doesn’t get any traffic. The runtime make the decisions removing sites, bases on many parameters, and even if you change the configuration, it may not apply, as the runtime may override that configuration.
If you are looking for your site to always be in memory, you may want to look into switching to Reserved Instance, in which your site(s) are running on their own VM(s) and the system is much more flexible in terms of resource utilization.
Yochay (PM Azure Web Sites)
If you're referring to the new Windows Azure Web Sites, I don't believe you have any option for controlling app pool timeout. This is a shared, managed service, where you simply upload your site, with the details of IIS etc. taken care of for you. You can look through the published management page, and you'll see that this is not an option.

Resources