I have tried two things. One is pre-compiling my ASP.NET MVC 3 project using aspnet_compiler, and the other is using RazorGenerator in the project to allow the views to be compiled. Using both methods, I still see that pages in my site are having to compile on the first access. I see csc.exe running on the server when they are first accessed and it doesn't happen the next time. Why are these pre-compiling steps not preventing this and thus letting me have faster first time access?
Pre-compiling an application won't improve the first request startup time because there are still many things that need to happen when the first request arrives:
The Application_Start method executes
Controllers and Views location are retrieved and cached for subsequent requests
...
You could use the AutoStart feature of IIS 7.5 and ASP.NET 4.0 if you want to preload an application in memory when the web server starts. This way the application will be hot and waiting for the first request.
Related
I have a C# MVC application hosted in IIS test environment with only one action method in APIController. Clients call this single method and depending upon the parameters different small processes are performed.
I am using IIS 10.0.17763. Application is built in .Net Framework 4.6
I have disabled these modules as i don't need them.
WebDAVModule
WindowsAuthentication
ScriptModule-4.0
DefaultAuthentication
ServiceModel-4.0
UrlAuthorization
FileAuthorization
The problem is that under load test from jmeter, all calls somehow stay longer in ResolveRequestCache State.
Can someone guide me the problem behind or suggest me something to check. I am not using any kind of caching due to business requirement.
Here is the Screenshot of requests states from IIS
Edit. I have removed some other modules too to check the effect.
Here is the list of loaded modules in my application
I am building an application which builds a cache which is of big size. The cost of building the cache is again if it is lost is huge.
Is there any way to save the cached data in asp.Net MVC3 applications ?
I think you should take another approach. could be, create database views for example
Keep in mind a few things, you can't have cached whole time because the app pool it's gonna recycle, so even you change the time interval, always gonna happen.
plus, changes in your app that can trigger the recycle
What trigger a immediate recycle?
anything changes in:
Web.config
Machine.config
Global.asax
Bin directory
App_Code
Views strong typed
What trigger a delayed recycle?
Occur with changes in .aspx, .cs/.vb files.
When browsing "http://dev.bindsolution.com/" the site takes too long to begin processing. Why this?
Are using "CSS Sprites", "css" and "JavaScript" minify although I do not think the problem is this.
Why the first request the site is extremely slow?
PS: I'm visiting from Brazil
When you first request the site after publishing, ASP.Net needs to compile and load the application.
It depends on what do you mean by first request.. Is it first request after an application (or app pool) has been redeployed/restarted, the very first request to your application is slow could be that IIS has to start the asp.net worker process.
also this link should provide you with more details: http://msdn.microsoft.com/en-us/library/ms366723.aspx
if you mean first request by any user well then there is an overhead on the files that needs to be downloaded by the user, also the site might be doing some process intensive stuff in Session_start, I would check all these..
Also if you have access to the code you could probably run some performance analysis on the same. I would highly recommend dotTrace by JetBrains.
FYI, I am no way associated with JetBrains. Just love their sw/tools
It could be that the first load is slow and subsequent loads are quicker because assets (js, css, images ) are cached for subsequent views and don't need to be loaded.
The firefox plugin yslow will give you a detailed breakdown on the sizes and loading speeds.
Also run smush.it ( part of yslow ) to shrink your image sizes. It will make the images smaller but there will be no noticeable difference.
IIS may have shut down some worker threads which need to be started, your appDomain will be starting and loading all classes from your dlls and JITing these to machine code, ASP.Net will also be doing it's own warmup (initialising all things required in the pipeline, possibly pre-compiling some views etc).
Update
The first request is slow because of the number of resources that the page has to load, once loaded, the browser will cache them do they will not need to be requested again (which is why there's the speed improvement).
Consider aggregating (and possibly compressing) all required resources on your own site, and referencing those in your pages.
My app makes requests to
http://www.brewerydb.com/api/breweries/?apikey=<key>&<parameters>
but I'm only given 100 requests per hour. I considered recording request instances in the app's database but during development I am often regenerating the database using code the Entity Framework 4.1 so that doesn't seem like it would work. Any ideas?
Some kind of database would be best.
If your regenerating the DB as you say, then store it in a different DB, or if you simply want to store basic info (date/time of hit), then nothing wrong with using XML or even a CSV file on your web server.
We have a very strange issue that we're dealing with.
We have an MVC 3 application that we are still developing, and Monday we started running into an issue with four specific routes (methods) in one of our controllers. All four of these routes are used in the management of roles and deal with either creating or editing a role. We have two different tiers of roles in the application, so there are two routes for creating a role for each tier, and two routes for editing a role for each tier. Both methods for the corresponding create routes call the same view, as well as the two methods for the corresponding edit routes. Both views call a shared partial view that contains the form fields that correspond to the properties of the role being created or edited.
Here's the issue.
If I attempt to hit these routes without running the debugger first, IIS will hang. It will not error out, throw an error, or even register the request in the IIS log.
HOWEVER, if I attempt to access those routes in the debugger, regardless of whether I have a breakpoint set up or not, the routes function as they should.
To make life a little more interesting, if I attempt to access those same routes AFTER I've run and shut down the debugger, the routes STILL function as they should.
We can reproduce this behavior on EVERY machine on our development team AND our staging server (except the debugging part on staging).
The methods that correspond to all of these routes themselves rely on a couple of methods in the same web service in our middle tier. Those methods work properly outside of the debugger in our integration tests.
We've checked for endless loops in the code, but can't find anything that would create an endless loop under these conditions. In fact, there's only one loop in the shared view, but it's a for each loop which shouldn't ever result in an endless loop.
Lastly, when I attempt to hit any of these four routes without running under the debugger or at least running it on a previous request, IIS essentially hangs. It will not time out. It will not throw an error. It will not log an error to the IIS log. Finally, it will eat up system resources the the point that you have to either restart IIS or reboot the entire machine.
Has anyone ever seen this behaviour before? Any ideas on how to get around it? I've NEVER seen this behavior before, and the only thing that anyone in our development group could come up with was some sort of permissions issue on a file, but we're not accessing the file system (outside of the view files themselves, and they have proper permissions) at any point during the processing of these methods.
I'm open to any and all suggestions.
UPDATE #1:
I have also posted this question on the ASP.NET forums and I had someone ask a question for more information. Here's my response to their questions.
What IIS are we talking about?
IIS 7.5. We're using the full-fledged IIS, not IIS Express.
What error?
That's just it. There is no error. No error is being reported. In fact, the request itself isn't being recorded in the IIS log for the site IF we're attempting to access these routes without the debugger running. If the debugger is running, everything works as you would expect it to.
VS Cassini?
Nope. IIS 7.5 that comes with Windows 7.
If you deploy on IIS a default WebForm project , does it works?
Yes. Without an issue. I actually have a number of WebForms applications that I maintain for customers running on my development box. They all work without any issue whatsoever.
If you deploy on IIS a default MVC project , does it works?
Yes. I have a number of sites running on this box. All of these sites are running without a hitch. IN FACT, the vast majority of routes on this site can be accessed without any issue. The vast majority of routes WITHIN THIS VERY CONTROLLER can be accessed without any issue!!!
To reiterate, this controller allows a user to manage users, roles, and permissions within the application. We have methods in there for listing, creating, and updating users, roles, and permissions. The routes that hit the methods for managing users and permissions work regardless of whether the debugger is running or not. The ONLY routes giving us issues are the four routes that I described above.
We currently have 19 controllers in this application, each with a varying number of defined route methods. EVERY OTHER route defined for the application is working properly and is not exhibiting this behavior. These are the only four methods (routes) in this one particular controller where we are seeing this.
UPDATE #2:
I've narrowed this down to a REST call (to a service that we control) within the controller. Here's the weird part - if I go into the REST service and immediately return a value (don't process anything), it still hangs outside of the debugger. If I'm running inside of the debugger or immediately after running the debugger, everything works as it should.
If I attempt to hit that REST service in fiddler directly, it works like a charm.
I'm going to try changing the URL in the service contract for the web service I'm calling and see if that works. Maybe it's something to do with the REST URL on the web service.
UPDATE #3:
Just to add further confusion, I set up Fiddler to act as a proxy between my MVC application and the REST middle tier. For EVERY other REST call within the application, the proxy gets the request. For this particular REST call, the proxy NEVER gets the request.
Now here's the annoying part. The WebChannelFactory that we use to call all of the methods in the middle tier through REST is created using a utility class in our MVC application. This code is used to generate every channel, so there's no difference between the requests that populate the list of users and the one that populates the list of permissions (the one that's hanging).
This is a GET request that's hanging, so I was able to call it directly in the browser. It works without an issue. The issues doesn't appear to be on the service end, but somewhere in the MVC application.
Make sure that you don't pass in ViewBag.Variable.ToString(), since it's dynamic, it will not work!