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!
Related
The Problem
I have a website running in IIS. If I rename or delete one of the layout page .cshtml files under /Views/ the site immediately begins throwing following yellow screen error as expected
The layout page "_Layout.cshtml" could not be found at the following path: "~/Views/_Layout.cshtml".
What surprises me is that if I recreate or rename the file so it is exactly like it was before, the yellow screen persists. Why is this particular 500 error sticky?
I currently think that this has something to do with IIS and is specifically related to error handling. The site immediately detects that the layout page file is missing. It does not immediately realize when the file is back in place.
Thanks!
Some interesting clues
This happens on all of my sites I've tried this on so far. It isn't related to a specific site
I tried this on two websites at the same time. On one site I repeatedly and consistently refreshed the page hoping for a success. On the other, I left it alone for several minutes before checking again. The site I leave alone will resolve its problems and find the layout page on disk again. The site I continually make requests to appears to display the error indefinitely.
What I've tried
I have reproduced the problem on Umbraco websites using Umbraco's default routing as well as regular MVC pages using custom routing. The problem is the same for both.
I don't have output caching configured in IIS
When I am reproducing the yellow screen error, I am able to reproduce the error in multiple browsers, so I don't believe it is related to browser caching
I checked on the httpRuntime in the root web.config and the fcnMode is set to fcnMode="Single"
I've fiddled around with the web.config customErrors and httpErrors. Nothing I've done here has affected the problem.
I am able to reproduce the problem on websites where there is no custom code for caching. No CDN. No load balancer.
Versions
IIS: I have reproduced the problem on Windows Server 2012R2 running IIS 8 and Windows 11 running IIS 10
CMS: All of the websites I have tested on so far are Umbraco 7 sites. However, I have reproduced the problem on pages that are routed using Umbraco's out of the box routing as well as pages that are just set up using MVC and aren't leveraging Umbraco.
It appears to be part of the behavior of FcnMode="Single". See https://learn.microsoft.com/en-us/dotnet/api/system.web.configuration.fcnmode?view=netframework-4.8. It isn't an issue with caching. It is a problem with the way that the site's file change notifications (FCN) are configured.
The sticky 500 behavior on renaming files happens when I use FcnMode="Single" but not when I use FcnMode="Default".
FcnMode="Single" will result in only a single object to monitor file changes. This single object is responsible for monitoring changes to files in the main directory and sub directories.
FcnMode="Default" will result in a separate object to monitor file changes for each directory.
Umbraco sites, by default, use FcnMode="Single". This makes sense because Umbraco sites cache under very deeply nested directories in /App_Data/. This can result in so many of these monitors that it can affect the performance of the site. There is a great explanation of FcnMode and why it matters for Umbraco here: https://shazwazza.com/post/all-about-aspnet-file-change-notification-fcn/
Unfortunately, it appears that the single file monitor can miss renames of files in some cases.
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 ☺
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!
I'm in the process of upgrading an old codebase containing jquery v1.2.7 to the v1.2.9. The corresponding UI upgrade is from v.1.6b to v1.9.2 (1.10 doesn't work with IE6). There are a bunch of ui plugins that are atleast 6 yrs old, and most of their authors no longer actively support them.
I took a layered approach of performing this. I first upgraded all the core files (jquery, jqueryUI), then upgraded inhouse js code (attr, $.browser) and such. Then I monkey-patched some of the plugins that had attr and browser. I've managed to work through all the bugs and errors so far. I now have a "clean" build, with a lot of the ajax functionality working as well.
BUT, I'm facing a pretty sticky issue with the facebox.js (yup THAT relic) plugin. I don't see any errors (js, network, or others) in the debuggers (IE8,FB,Chrome), but the facebox dialog displays incorrectly. It still displays the content inside it, but it is transparent and the background and edges do no show. I checked all my css as well as validated using w3c validator. Due to an NDA, I can't post the markup here. I realize that without the markup, even the considerable expertise here might not be able to give a complete solution. Could someone atleast give me some pointers on what I could be overlooking, or things to look for? TIA
eastwood
As you said, without markup it's difficult to figure out what's going on there, and my answer might be really stupid - but since you don't get any errors in the debug consoles and the box is transparent - is it possible that the images are missing/incorrectly referenced in the CSS?
Not sure how this old facebook.js plugin works, but I've seen one some time ago that used images for backwards compatibility with IE6 (for alpha transparency/rounded borders) - but not always. I think for modern browsers it drew that stuff itself. (pretty much like Facebook did it itself on its site)
So perhaps the error is related to JavaScript expecting images/etc. to be handled by CSS, but the CSS uses an only-IE6-hack?
I would be grateful for some pointers on how to troubleshoot this problem. Quick summary of the situation:
I have a large document (200K) divided into five main sections of inequal length, each of which corresponds to a jQuery UI tab.
The page works perfectly in Safari for Windows, Safari for Macintosh, Opera, Firefox, Chrome, and IE.
The page used to work on the iPad too but it no longer does, and it's the iPad that has changed, not the page.
On the iPad, the tab-content is now getting cut off. E.g. one of the pages is a glossary that runs from A-Z and the page cuts off at the letter -H-. It used to scroll all the way to -Z-. For some reason, iPad Safari is not giving each Tab the full amount of vertical space it needs for its content.
I've looked at the jQuery UI code for the show tabs and it appears to be changing CSS classes hide/show, but I'm no ninja javascript coder. How do I begin to figure out what's wrong on the iPad when my page works as expected on every other browser?
EDIT: The page seems to be working fine on the iPad2. It could be a caching issue and the page might stop working at some point even on the iPad2--I could only test at the Apple store. But I believe the markup and coding and jQuery ui are essentially OK, and it's a iPad Safari issue.
I can't trouble-shoot myself without the code, but the by far best way to trouble-shoot situations like this is to use a tool called Weinre. Obviously if one browser (the iPad's) is having trouble, you need to troubleshoot directly with it. That's difficult since the iPad doesn't have developer tools, but Weinre can actually give you (most of) that, over the network.
Follow the instructions here, but at the least you need to provide a ~/.weinre/server.properties that contains this:
boundHost: -all-
httpPort: 8081
reuseAddr: true
readTimeout: 1
deathTimeout: 5
That will tell weinre to listen on every IP on the port 8081. Start Weinre (via the OS X runner or with java -jar weinre.jar on the command line.
Then you add a special script tag in the main page:
<script src="http://YOUR_IP_NUMBER:8081/target/target-script-min.js"></script>
After this you start Safari or Chrome and go to http://localhost:8081/client/. If everything went as planned you will see the Weinre interface, which is a subset of the WebKit developer tools.
Now connect to your development machine with the iPad or simulator. If the script tag is correct Weinre makes a connection to the iPad and you have a fairly large subset of WebKit's developer tools at your disposal for trouble shooting. Good luck!
I'm sure this isn't the answer you're hoping for, but it sounds like a bug that should be reported to Apple.
You have a page that works perfectly on every other browser and I think its in Apple's best interest that it works on the iPad as well.
There might be other pages out there that used to work, but now don't, so I would consider this bug to be pretty high priority.