Lazy loading content web app in amazon EC2 - asp.net

I'll give a context of what happened to understand better. I used Azure services app to keep my application running, but I created a new datacenter on amazon and migrated my web app to the new server.
I use the iis in it to store the application. It's in asp.net and first there was a slow issue with me. bundles, but with this new migration I saw that was too slow to load them, in azure app services took about 200ms, already on the new server was for 3 seconds each bundle on screen, I solved this problem just pointed the way of scripts without using bundle.
The way I did it was a palliative solution and I didn't solve the root of the problem, the loading time on the screens is still a bit time consuming and is spoiling the user experience.
In azure the same application in their service app does not take so long, already on the server running on iis is taking too long and I think it is some configuration but I was not successful.
This is the application in azure:
azure
This is the application in amazon:
amazon
This both examples is the same app, same database and same user account. I believe the problem is not in the application but in the server config.
Someone can help me about that?

Related

Azure App Service Web App resources and user controls loading slowly

We are just starting to deploy our hosted web application in an Azure environment. We have the database running as an Azure SQL Database and the web application running as an Azure App Service Web App (including a continuous WebJob). We are having some significant performance issues with the Web App and I am hoping to get some advice on how to resolve these performance issues.
Here are some key points:
The Web App is deployed as a compiled web application (binaries, markup, *.resx files), not source code
The Web App is deployed via FTP
The Web App has "Always On" turned On
The App Service is running in the South Central US Azure datacenter
The Azure SQL Database is also running in the South Central US Azure datacenter (so database latency should be minimal)
We have an exact replica of the Web App (same binaries, etc.) running on a non-Azure server in a datacenter in Los Angeles (if database latency were the issue, this site would have worse database latency)
Both instances of the Web App (Azure and non-Azure) are connecting to the very same Azure SQL Database (running in the South Central US Azure datacenter)
I have been testing from a workstation in Utah – not particularly close to either web server
On any “cold” request (site has been idle for a period of time), the Azure site seems to be significantly slower. Pages that load quickly from the non-Azure server take a long time (e.g. 20 seconds or longer) from the Azure server. The content is the same, and both apps are accessing the same database – so I don’t believe it is a database issue. I have narrowed it down to two .NET functions that seem to be the problem:
System.Web.UI.TemplateControl.GetLocalResourceObject(string)
System.Web.UI.TemplateControl.LoadControl(string)
The application includes *.resx files for a few different languages. When a request comes in, it uses the culture in the request header to load the correct resources. The GetLocalResourceObject function seems to be compiling the *.resx files on the fly, which seems to take several seconds on the Azure server. I may need to try something like this to prevent Azure from compiling *.resx files on the fly.
Some of our pages load controls dynamically, hence the call to the LoadControl method. These controls are deployed as *.ascx markup, but the code-behind is already compiled into a *.dll in the .\bin folder. Even though the controls are already compiled, it appears that the LoadControl function is trying to compile each control, which takes several seconds on the Azure server.
A “warm” page access seems to go more quickly on the Azure server (almost as quickly as the non-Azure server), probably because the resources and controls are already compiled and still in memory. I have yet to be able to determine at what point the resources/controls have to be recompiled.
I am trying to figure out the best way to make the site respond well, even on a “cold” request. I have tried running aspnet_compiler.exe on the Azure App Service server (via Kudu CMD). That seems to work sometimes, but it has not been very reliable (sometimes it doesn’t seem to work, or the process doesn’t seem to complete). It also seems that, even after compiling the site, the problem returns after a period of idleness.
Our primary objective is to get the Azure App Service Web App to perform acceptably. It seems that the only way to do that is to force the Web App to precompile the resources and user controls so they are not compiled on demand. I have yet to find a reliable way to accomplish this objective. Any help or insight would be appreciated.

Hosting and update version concurrency for asp.net project

My question is simple and straightforward: I am new to hosting and its process. I have Web Application and I have to host it. I dont know where to host and how? In my list there are Godaddy.com and hostcat.com for hosting and I want to use filezilla for updating the Application. But My concern is my application have Payment gateway and I do not want my site to get down for a minute while updating the version.
Now my question is How to maintain concurrency while updating the application? Any solution where should I host the application and what software should I use for updating.
Any solution or tutorial are highly appreciated.

How to restart an ASP.Net Application automatically when it goes down

I have developed a asp.net application which is deployed on his personal server. The application is running in the background and updating his e-commerce database automatically. I have used Quartz.net for scheduling purpose.
My problem is that the application gets stopped after certain period (3-8 hours) of time.
I want a way to restart the application automatically as soon as it goes down.OR alternatively a service which visit the application periodically so it goes live.
Note: I have access to my client server and can yous windows scheduling if there is any solution relatively.
I have also read similar post but had no luck.
Your prompt response will be highly appreciated.
Thanks

IIS App Pool/Restart and ASP.NET

We are using IIS7 to host an asp.net web-based application.
In this environment administrators and developers can deploy code to the application on a regular basis.
The new code or app goes as a DLL to the ASP.NET bin folder. Upon deployment of the new DLL, IIS restarts the process, impacting (slowing down) all online users.
Is there a way to configure IIS to run the process in the background and once ready make the switch from old state into new without impacting the users?!
Thanks in advance for your feedback!
IIS already does this, that's what recycling is all about. IT's loading the DLL's while the old version of the application is still running. only after this is completed the recycling is complete.
However loading the DLL's is only part of getting web applications ready, there might also be initial loads like loading/caching the user db etc.
These actions are not part of the recycle process, they happen after all DLL's reloaded and the recycling is already completed.
A while back I ran into this issue with an application that had a huge startup time due to heavy db activity/caching during startup. So I was interested if there is some functionality that allows us to execute code before the recycle is marked as completed, so that the application is first considered recycled when everything is ready to run. Basically what I wanted is some kind of staging functionality.
I was in contact with the IIS team regarding this issue, sadly they told me that no such functionality exists, nor is it planned.
To solve this you could try do the following:
Use alternating deploys:
You setup 2 Websites with separate application pools. One of them is the LIVE website the other one is the STAGED website. If you want to deploy changed you simply deploy to the STAGED website. After everything is loaded/cached etc. you switch the URL settings of the web applications to reroute incoming requests from the LIVE to the STAGED one. So the LIVE one becomes the new STAGED and the other way around. The next deploy would then go to the new STAGED again and so on.
UPDATE
Apparently they have created a IIS Module that provides this functionality by now:
IIS Application Warm-Up Module for IIS 7.5
The IIS team has released the first beta test version of the
Application Warm-Up Module for IIS 7.5. This makes warming up your
applications even easier than previously described. Instead of writing
custom code, you specify the URLs of resources to execute before the
Web application accepts requests from the network. This warm-up occurs
during startup of the IIS service (if you configured the IIS
application pool as AlwaysRunning) and when an IIS worker process
recycles. During recycle, the old IIS worker process continues to
execute requests until the newly spawned worker process is fully
warmed up, so that applications experience no interruptions or other
issues due to unprimed caches. Note that this module works with any
version of ASP.NET, starting with version 2.0.
For more information, see Application Warm-Up on the IIS.net Web site.
For a walkthrough that illustrates how to use the warm-up feature, see
Getting Started with the IIS 7.5 Application Warm-Up Module on the
IIS.net Web site.
See:
http://www.asp.net/whitepapers/aspnet4
If you use ASP.NET 4 Auto Start feature:
You can still choose to auto-recycle the worker processes from time to
time. When you do that, though, the app will immediately restart and
your warm up code will execute (unlike today - where you have to wait
for the next request to-do that).
The main difference between Warm Up and Auto Start feature is that the Warm Up Module is part of the recycling process. Rather than blocking the application for requests, while running the init code.
Only thing you get by using the Auto Start feature is that you don't have to wait for a user to hit the page, which does not help your case.
See the Gu's blog post:
http://weblogs.asp.net/scottgu/archive/2009/09/15/auto-start-asp-net-applications-vs-2010-and-net-4-0-series.aspx
UPDATE 2:
Sadly the Warmup Module has been discontinued for IIS 7/7.5:
http://forums.iis.net/t/1176740.aspx
It will be part of IIS8 though (It's now called Application Initialization Module):
http://weblogs.asp.net/owscott/archive/2012/03/01/what-s-new-in-iis-8.aspx
UPDATE 3:
As pointed out in the comments the Warmup Module resurfaced for IIS 7.5 as Application Initialization Module for IIS 7.5 after IIS 8 was released:
http://www.iis.net/downloads/microsoft/application-initialization
The first part of ntziolis answer is a wee bit inaccurate. The worker process isn't being recycled or restarted, it just keeps running. If this were the case, then in shared pool environments you would have sites knocked out every time a new one was deployed.
When you deploy a new ASP.NET application it's the site's "Application Domain" within the worker process is torn down, not the pool process.
In addition pool recycling is a completely separate concept to deployment
At this point in time in the commercial life of ASP.NET, during a deployment, a site will be in an inconsistent state until all of the site is deployed. There is still no good story about this from Microsoft at this time for single site on a single server deployments.
This is why ASP.NET has the special App_Offline.htm page. It's there so you can enable that page, deploy and then turn it off.
The second part of ntziolis answer is nearly correct but you don't need two sites or two application pools. You just need two file system folders that switch between being the physical folders for the site...if you're on a single server and not behind a load balancer or ARR.
If your sites were on a web server behind a load-balancer or ARR then having two different sites would make sense, you could route requests from one site to the other and round-robin on each deploy.
Obviously if there is a large amount of user generated content (uploaded files and the like) then you'd map a virtual directory in your site to a common location for this data.
In larger scale deployments where your app is running across (for example) a load-balanced environment you can do more sophisticated deployments.
For related questions please see:
How Do I deploy an application to IIS while that web application is running
Publishing/uploading new DLL to IIS: website goes down whilst uploading
Is smooth deployment possible with componentized ASP.NET MVC apps?

Why does IIS on Azure Web Roles need to recompile ASP.NET apps so often?

I have ASP.NET applications deployed on a number of different environments (AppHarbor, Azure, DiscountASP.NET, GoDaddy, etc...) and one thing that bothers me with my deployments on Azure is that my low-traffic websites get JIT-compliled if there hasn't been a request for more than a couple of hours.
Obviously I could solve this by increasing the amount of traffic to my site (I'm being facetious) or by trying to do some hacky things with precompilation, but I'd rather understand why the site needs to be compiled constantly in Azure. I've never noticed this issue on other providers (even GoDaddy) for low-traffic sites - is there some reason for this, and is there anything I can do in the Azure config files to stop this?
Bump your app pool timeout settings with a web role startup task. Steve Marx has a post on how to do this in Azure. You can login with remote desktop to change this to verify - but that setting would get blown away next time you deploy.
On other environments, the app pool settings are probably configured differently. This bugged me for a while when I first set up my Azure site.

Resources