I have a Azure website consisting of a WCF endpoint and a MVC website running on Azure. It runs on a basic medium/large tier - so no cap in CPU as Free or Basic has. This has been running perfectly for 6 months probably, with regular deployments and updates. And performance has as expected kept consistent. But now suddenly it takes forever to load the MVC website.
The flow is as follows; we receive a call via the WCF endpoint and then we direct people to a URL that is the MVC web site. All resides on same "web site" inside Azure.
The strange thing is that I can see no difference in my log files. The WCF endpoint responds as quickly as always and from what I can see the heavy lifting inside the MVC also responds as expected, but still the user is left waiting forever on the specified URL?
As said I can't see anything in the performance logs for the MVC controllers, so somehow it seems to be the https request itself that takes ages, but how do I debug or measure this?
I am in the process of getting Visual Studio 2015 to see the remote profiling that can be generated through KUDO - but somehow I don't think that the problems resides here. I am kind of blanking so any thoughts on what could be wrong and how to debug would be appreciated. Also if anyone knows that Azure has released something within the last couple of weeks that might have slowed the application down.
Any chance that you have Application Insights turned on for the MVC site? It has a feature that will track dependency calls and should be able to give you a good idea of what is taking a long time.
https://azure.microsoft.com/en-us/documentation/articles/app-insights-asp-net-dependencies/
Related
I'm working on an ASP.net MVC project and I noticed that when the web app gets published, IIS doesn't build a cache or anything for the views until a controller has been hit. So in other words it can take a very long time for a visitor to get the page loaded if they happen to be the first person to visit the page after the whole project gets republished.
To counter this, I'd have to manually hit every endpoint with a view in the project once. When the project first started this was a simple task but as you can imagine right now this is not maintainable.
My question is how do I execute a batch of curl commands to the endpoints with views in the project? I'm not sure where to start. Is there a programmatic way to create the batch command and append it to the AfterPublish event?
The behaviour you're encountering is due to Application Pool Start Mode in IIS. Instead of implementing AfterPublish events, you're probably better off configuring your Application Pool to do what you want it to do.
Start Mode
A few web applications take a significant amount of time to start up. IIS by default only launches a worker process when the first request for the web application is received. So for the web applications that require a longer time to initialize, users might see slow responses.
For such applications it is a good idea to launch the worker process as soon as IIS is started. The application pools have a startMode setting which when set to AlwaysRunning launches the worker process for the application pool as soon as IIS is started.
IIS 8 provides you this setting in the Application Pool Settings UI.
Source: https://blogs.msdn.microsoft.com/vijaysk/2012/10/09/iis-8-whats-new-application-pool-settings/
If you really want to run those actions after you publish the website, you'll have to learn more about the Visual Studio build process. This link can get you started: https://learn.microsoft.com/en-ca/visualstudio/msbuild/how-to-extend-the-visual-studio-build-process?view=vs-2017
IIS has to start the application again after I rebuild the website, it takes a very long time and it cuts into productivity.
I am wondering if I can somehow replace the MVC website with a small console application that listens to a port and returns a string that is then interpreted by the browser as valid html. I am not sure if this was done.
Something very lightweight.
So that it does not take 30-50 seconds on each rebuild, to see my site in action.
I want to build my app, then immediately do a request and test it and not wait almost a minute.
Is there something that does that?
There is a way to build Self-Hosted Web Api applications.
It can be console exe, or setup to run as a service.
The ASPNET engine, is designed to compile itself (views, etc), but a minute? This might be due to the weak PC, for instance.
You can use the Browser control in a windows form app. But it is not recommended, there is no way of avoiding IIS restart since your files have been changed.
I am trying to publish my app on the web. It is very simple app, I have just start to learn MVC. To publish my app I have followed the instructions given at http://www.asp.net/web-forms/overview/deployment/visual-studio-web-deployment/deploying-to-iis. However I cannot see app from other PCs. I see it in browser from the PC where I have created it, but when I try to open it from another PC it is not visible, the link I am trying to access is the one I created during publishing - http:/localhost/WebApplication1. I am not sure what I am doing wrong. Or maybe the example I followed is not correct for the thing I want to do. Could,please someone tell me what I am doing wrong? Thank you in advance.
If you publish your site on localhost, you'll see it only in your local network. To publish it on the web, you'll need some web hosting service. You can try, for example, Microsoft Azure, it works perfectly with ASP.NET (not too surprisingly, as it comes from Microsoft), has a 30 day free trial period and otherwise is relatively cheap for low usage.
In dev environment I am using the ASP.NET configuration tool in Visual Studio to create a few users for testing. As I movel closer to QA and Production, I'm wondering what is the best way for me to automate the creation of a large amount (1000's) of users after application deployment.
I have a csv with all the usernames and passwords, roles etc. and I wan't to avail of the encryption and password salting security that is built in. I do not want to manually "Register" all these users.
I'm just not sure if this is something I can do (or instruct a db admin to perform for me).
Does anyone know of a way to achieve this?
Any assistance would be greatly appreciated.
Regards
The simplest solution would be to set up a "CSV Upload" form. The CSV would be processed by an MVC action calling Membership.CreateUser in a loop.
Probably, the performance of this will be good enough.
There's a few ways that I know of approaching a batch processing problem on an ASP.NET site.
Because of the wonky way an ASP.NET site's application pool can get recycled, batch processing is usually done on an external process.
Windows service
One way is a separate windows service, which gets the new excel and pumps that data in, and has a timer which keeps going around. I've seen this used often, and it is quite a pain, because it takes extra work to make it easily deployable.
Update ASP.Net membership from windows service
CacheItem
Second way is to use CacheItems and their expiration timers to do batch processing, what you do is you define a cache object with a long timer, and when that expires and the Removed-callback gets called, you do your database work. This is good because it deploys with your ASP.NET site, and you have your code in one logical place.
https://blog.stackoverflow.com/2008/07/easy-background-tasks-in-aspnet/
Workflow Foundation
Third way, is to make a workflow foundation service. That service gets a call from your ASP.NET site, which instantiates a WF service, that does some db work with your excel file, and then it goes into a while-loop with a delay of a month in it. This is good, because it is not tied to the lifespan of your ASP.NET application pool - you get more control, and this logic can be separated into a different IIS hosted WCF service.
http://msdn.microsoft.com/en-us/library/dd489452.aspx
Integrating with data is always a pain though, remember that the solution that gives you the least work and least chance of failure when deploying is the best solution.
We are getting ready to do a an initial deployment of an ASP.net MVC app on IIS 6 running on Windows Server 2003. We've been reading about performance issues involving the use of extenionless urls in MVC applications specifically in the case of removing the '.aspx' extension from the controller portion of the url.
Has anyone who has deployed an MVC app in the past experienced any performance degradation in this area? Was it noticeable, and was it worth it for having the cleaner URLs? Our application will rarely have to deal with more than 1000 or so concurrent users.
Edit: Thanks for all the responses, it's working quite well, although there are a few strange requests going through as some people mentioned, I think we can work around these using the suggestions mentioned here.
We recently deployed an app that received approx. 20 million page views over a 3 month period using the IIS 6 wildcard mapping setup and had no performance issues. We did host most of our images on a CDN, but other static content was served directly from the site.
For what it's worth, IIRC, the asp.net handler will pass requests for static file types back to IIS through a default handler for processing. The only practical performance hit is the time during that process that a worker thread is occupied identifying and transferring the request. In all but the most extreme scenarios, this is too trivial to matter.
As an extra note, we load tested the application I mentioned prior to going live and found that it could handle nearly 2000 static requests per second and around 700 requests per second for pages that involved database activity. The site was hosted on 4 IIS 6 servers behind a ZXTM load balancer with a 1GB internet pipe.
Here's a link with some good advice on the whole static file handling business:
http://msmvps.com/blogs/omar/archive/2008/06/30/deploy-asp-net-mvc-on-iis-6-solve-404-compression-and-performance-problems.aspx
The problem with not using extensions on IIS 6 is that you don't want static requests to go through the ASP.NET stack. If all of your static requests come from one (or two...) subfolder(s), you can exclude them. This should fix the performance issue.
Quoting from the linked post:
Now, to remove the wildcard map on the
/Content subdirectory, open a command
prompt, go to c:\Inetpub\AdminScripts,
and run:
adsutil.vbs SET /W3SVC/105364569/root/Content/ScriptMaps ""
… replacing 105364569 with the
“identifier” number of your
application. (Also, you could replace
“Content” with the path to any other
directory.)
We ran a fairly busy site with IIS6 wildcards on for extensionless URLs and although we never noticed much of a performance hit, we did have a little hack that worked quite well:
For all folders that contained only static files, like /css, /images, /scripts etc, in IIS we set them as their own application, and disabled the wildcard setting, which meant IIS handled the requests rather than routing through ASP.Net.
Url rewriting can help you to solve the problem. I've implemented solution allowing to deploy MVC application at any IIS version even when virtual hosting is used.
http://www.codeproject.com/KB/aspnet/iis-aspnet-url-rewriting.aspx
Instead of serving all the requests by ASP.NET, you could specify e.g. mvc as the extension (say index.mvc) and map that extension to aspnet_isapi.dll in IIS 6.
This means only known extenions will be processed by asp.net, others like static files stay the same as before i.e. served by IIS itself.