I have an MVC 5.x app which has had its views precompiled and merged into a single assembly. Even after all this the first request to a view after AppDomain startup is slow, it does not matter which view is requested as they are all slow the first time the view is requested. Digging in with MiniProfiler I can see it is the "Render" time on the view which takes the majority of the time and upon additional requests to the view the Render time is reduced by about 90%. So to be clear it is this first-time Render that is taking allot of the time. I was not expecting to see this bit of slowness due to the fact all of views have been precompiled and I do not believe it is the JIT that is causing this massive slow down...anyone have any guesses or insights?
Please note, this is not the very first request of a web application, this is the first request of a particular view/page. For example, for the test below the app had been running for hours and was taking requests constantly but the test captured the first request for this view.
First Request
Second Request
Strange! In order to be 100% sure what exactly happens, however, I'd do the following:
I'll redirect the run-time compilation (yes, there'll be one since at
least Global.asax needs to be compiled) like this:
<system.web>
<compilation debug="true" targetFramework="4.5" tempDirectory="c:\temp\asp.net" />
...
</system.web>
I'll investigate the contents of the folder before and after the
first run. Maybe it'd be even better to have a copy of the original.
From your description of the problem it seems like everything should be just fine and there would be no differences between the runs. Still comparing contents of the folder before and after may reveal some difference.
Another cause might be some caching but I can guess you have already sorted this up.
I struggled with the exact same issue for months: It happened to me in some views only.
Apparently, the rendering of the views is not that straightforward as I thought, since MVC needs to run a couple of operations to determine the exact .cshtml to use for an action, its partial views if you have any, etc etc.
What did the job for me is to use Razor Generator which processes Razor files at design time instead of runtime. (if you wanna give it a shot, I suggest first trying it with a view you know takes time to load at first attempt).
From the website:
One reason to do this is to avoid any runtime hit when your site
starts, since there is nothing left to compile at runtime. This can be
significant in sites with many views.
The downside of implementing the Razor Generator is that you no longer need the .cshtml files: so if you want to change a view, you have to recompile the project. But that's not an issue necessarily, at least not for me.
Install the Razor Generator from the VS extension gallery first (like it's explained on the website) and then the nuget package.
Trust me: you are gonna be so relieved you're gonna cry ☺
Related
Basically any place that a MVC resource is needed in my application, it is being listed in the error list (234 errors, almost every single one is the exact same error).
I am able to get intellisense when I type System.Web.Mvc., and add a Controller, but after building, the line which the Controller was added to shows in blue font, but it is underlined.
I have literally tried so many solutions from Stack, most often discussed is:
Remove reference to System.Web.Mvc and re-add. Set copy local to true.
Screenshot of subset of errors below.
I am surprised that it is being flagged here, when it is recognizing Controller in the inheritance.
Here too
This is never the nice answer... I recreated the solution, and very carefully chose all of my options when configuring. I built to the browser after all changes, and so far everything is working out.
I am running an instance of Umbraco 6.1.x and it has started throwing 404 on published pages.
My page structure is as follows,
Content
Home
About
Course
...
Component
Home
About
Course
Where component holds all resources and modules (HTML sections and stuff) for a page and using a partial view macro I dynamically load all components at runtime for a specific page.
We are facing an issue where we get 404 on every page after a full republish once we hit the HomePage. Before hitting home page they are all fine, but the moment we hit the homepage they are all throwing 404. By overriding the handlers I found out that they are hitting ~/umbraco/RenderMvc!
Any idea what can cause this?
Thanks in advance.
EDIT:
It is actually throwing:
No template exists to render the document at url '/'
considering the aforementioned scenario.
I have proper allowed template setup and property on nodes are showing the correct template associated with the respective items. Not sure why it's losing template info. I can force it to load under correct template using ?altTemplate=templateName.
Some pointers, we have a view in Views/Shared folder (apart from macro partials) tied to a surface controller.
One thing I would like to say is, we are using nested (library.RenderMacroContent with Umbraco markup) in our partial views and I have realized that the whole page throws 404 if there's a page with a link to the broken page which is broken (i.e. page got re-created and on t==e of the components is holding a link to the page with previous id). Suggestions?
did you get to the bottom of this? We're having exactly the same problem at the moment, on the same version of Umbraco.
I've noticed that when it happens, the umbraco.config becomes either corrupt or rolls back to a much, much earlier version, with all sorts of attributes missing. This lead us to believe it was a sync issue between the DB and umbraco.config.
We initially thought we had solved it by deleting App_Data > TEMP > ExamineIndex and recycling the app pool etc. Maybe give this ago, as it fixed it for a while for us, but alas, the demon has reared its ugly head once more. We are still in a full on dev stage though, so the constant changing may be complicating it further for us - perhaps it will be a fix for you.
If you have any more info, or even a fix, it would be greatly appreciated.
Cheers
EDIT:
Ok, I think I've solved this now, but only time will tell. Try emptying your recycle bin & then republish entire site.
I managed to consistently recreate the bug using IIS SEO site analysis. Each time I did this, the log threw up an error 'cannot find node id xyz', turns out that (and other) nodes were in the recycle bin. Upon emptying it the errors stopped. Good luck!
Ok, I'm building a PoC for an ASP.NET MVC 4 mobile application that needs to have offline capabilities, and I have several questions about whether I'm designing the application correctly and also what behavior I will get from the cache manifest.
I'm progressing with the PoC but I'm observing a weird behavior on a working controller action right after adding the manifest attribute to my Layout.cshtml.
Before adding the attribute, every time I requested that URL, a breakpoint I had on the controller action would be hit just once every time. After adding it, the breakpoint is being hit 3 times the first time the page is requested (first time ever), and it is no longer hit at all until I manually delete the local cached manifest.
Nothing else changed, so this makes me believe that this type of offline caching works differently that the regular way in which browsers cache works. I'm thinking that since the page I'm visiting is listed on the manifest, the breakpoint is hit the first time because I requested the page, and then a second time because it is listed on the manifest.
That is weird already. Why is that?
Besides that, why is it being hit a third time?
I've verified that the behavior goes away if I manually delete the locally cached manifest and also remove the manifest attribute from the html tag, so this is most likely the culprit.
Can anyone explain what's going on please? Thanks.
Well, no one replied and I was no longer able to reproduce the breakpoint being hit 3 times, although I'm sure it happened a few times.
And yes, appcache or html manifest caching works in a different way than regular caching.
With the first visit a page, that had the manifest attribute on its html tag, the same page being listed on the manifest made a request to the server for the same page.
I'm making the answer a wiki in case someone wants to add anything.
I've got a strange problem; normally when you set debug=false in your web.config file and compile your web application in Release mode, it increases performance. For some pages on my site, it's majorly slowing down the rendering. Here's the page in debug mode:
... and here's that same page in Release mode with debug mode turned OFF:
No, I didn't get those two confused. What on Earth could be causing debug mode to be rendering the page 3 times quicker (if you ignore the controller and SQL performance, it renders the page FIVE times quicker)?! Is there anything obvious I could have misconfigured?
Short answer: the problem was Microsoft.AspNet.Web.Optimization beta2; it is doing something extremely inefficient and will add a second onto your page rendering time. If you're using it, upgrade. Now.
I took Steven's advice and used MiniProfiler to see what was causing the slowdown in the view. It was the System.Web.Optimization.Scripts.Render() rendering of the jQuery UI JS:
As per the advice of this question (also, this question seems to address the issue), I upgraded:
PM> Update-Package Microsoft.AspNet.Web.Optimization
Updating 'Microsoft.AspNet.Web.Optimization' from version '1.0.0-beta2' to '1.0.0' in project 'Bacp.Assess.Web'.
This upgrades both Microsoft.AspNet.Web.Optimization and WebGrease. Here's the same page after I upgraded:
Uhm. :-) I just knocked 99.9% off the rendering time of the page. Other pages on my site are rendering a lot quicker too. I don't know what Microsoft.AspNet.Web.Optimization beta2 was doing but it's like a ball and chain around ASP.NET!
When debugging my MVC3 app in Visual Studio using IE9 I see lots of small "script block" entries for my page. My page relies heavily on AJAX, and some actions result in replacing sections of the DOM with partial views coming back from the server.
What I'm seeing is a growing list of these "script block" entries - should I be worried about this? Will this ultimately be a performance problem when the app is live?
Note: the script blocks are quite small bits of code - I've moved most of my significant javascript into their own .js files.
Mm, I thinks it's more of a personal style thing with modern browsers, but if nothing else, trying to contain all the script for a view in one block at the bottom of the page will make for easier debugging and your future self will thank you for it!
As a general rule of thumb I will only have script blocks in pages that need to use the document.ready or variables from my viewmodel. Otherwise, I would move all the functions into their own js file. It helps keep the views cleaner and the browser will load the page faster since it won't block loading the page when it hits as many script tags. Plus, it will make debugging easier since you can go straight to the js file instead of having to find the function within the HTML.