Around 90% of the pages for our websites have no .Net code embedded in them yet are published as .aspx files. I want these to render as fast as possible so I'm removing as much as I can.
Does the .Net page directive have an impact on performance? I am thinking about two factors; the page speed for each GET and what happens when the file changes. The CMS system re-creates each page daily and I'm wondering if this triggers the ASP.Net compilation process.
If your pages have no .NET code and rendering speed is your goal, you may wish to consider changing the extension to .html. Any .aspx page will be passed to the .NET ISAPI filter by IIS and go through the entire chain of HttpModules, then will be handled by the Page HttpHandler. Using a .html extension would trigger IIS to process the request using the Static Resource ISAPI filter, which has a much shorter pipeline and is tuned for resources that run no code.
The <%# Page %> directive is not required. Without it, the default values for Language and other stuff will be assumed.
By changing a .aspx file, it'll be recompiled (it doesn't recompile the whole app though):
Any changes to a dynamically compiled file will automatically invalidate the file's cached compiled assembly and trigger recompilation of all affected resources. The next time a request to the code is made, ASP.NET recognizes that the code has changed and recompiles the affected resources of the Web application. This system enables you to quickly develop applications with a minimum of compilation processing overhead. (Note that depending on the change to the resources, the result can range from recompiling a single page to recompiling the whole Web site.)
Ok, put them in - just to be sure.
.NET pages are ALL compiled, page directive or not. nothing changes. Post compilation, they are as fast as it goes, as they turn into a class (type loaded once) that just executes.
Note that the post by Mehrdad Afshari is factually wrong (sadly I can not tag it). Any page change triggers a complete recompile AND restart of the appdomain. Acutally any FILE change does so, as long as it is outside App_Data and ASP.NET can see it (i.e. non-hidden flag on the directory / file).
Related
I'm working on a .Net/ASP project and my responsibility is to work on the design part of the application only (mostly changing css, js, images, and cshtml files)
I'm working directly on the server, so my app is not running in visual studio or locally or any environment where I can rebuild the app.
That being said, any changes I make to the website takes about 45 minutes before it shows up (I do clear browser cache every time as well).
Is there any way I can manually clear the application cache or rebuild it on the server so my changes start showing immediately?
This is something I added to the we.config but still not helping:
<caching>
<outputCacheSettings enableOutputCache="false"/>
</caching>
Well, if I'm not mistaken the cache you're targetting is not about this kind of resources as they're simply not processed by .NET. This outputcache is rather about the final HTML rendered. So I don't think that's where you should be looking. But there may be some kind of proxy somewhere caching those resources aswell.
To avoid client/server caching problems with CSS and javascript, I usually add a time ticker to every request avoiding them to be cached client-side. It should also override any "server caching" of those resources, and I would advise testing it manually before putting an automatic solution in place. so, if you're including js file that way :
<script src="/mypath/myscript.js"></script>
you could just do that :
<script src="/mypath/myscript.js?123></script>
and see if you get the changes in the file immediately now. If yes, just automate the addition of that number (ideally a timestamp so it's always different on each request) to every javascript/css inclusion you make...
I created an aspx page and viewed it in Firefox and Chrome and it worked correctly, running the C# code. But when I make changes to the page (including deleting everything and serving up a blank page), both browsers continue to show the original compiled aspx page!
It appears that ASP.Net (the web server) is not recompiling despite changes to the aspx file. The only way to get it to recompile is to change web.config and then restart the web server!
I even added the following code, but it still loads the original page:
<script runat="server">
Sub Page_Load
Random rd = new Random();
Response.AddHeader("ETag", rd.Next(1111111, 9999999).ToString());
Response.AddHeader("Pragma", "no-cache");
Response.CacheControl = "no-cache";
Response.Cache.SetNoStore();
Response.Expires = -1;
End Sub
</script>
TEST I DID TO RULE OUT BROWSER CACHING:
Created an aspx page and loaded it in firefox only (not in chrome)
Changed the aspx file
Loaded aspx again in firefox but got no changes
Loaded it (for the first time ever) in Chrome and it still showed the old version!
Using Apache and Mono, not IIS
This appears to be a Mono+Apache on Linux issue. It doesn't see changes to pages that have been compiled. The only workarounds are:
Restart Apache webserver (this causes it to see them as changed) - only takes about 2 seconds
Delete the temporary files in "/tmp/www-data-temp-aspnet-0/" (This can be a bit buggy so #1's a better choice)
Check whether your web application is a Web Application project or a Web Site project. If it was a Web Application, you will need to compile each time you change something, whereas web site projects allow changes to get reflected without compilation. Also, you can use Ctrl+F5 in browsers to get a non-cached copy of pages. Hope his helps.
Read details here
Short Answer: It is browser's fault, and it is expected behavior by design. Force cache refresh in browsers (Ctrl-F5 in IE).
Correction: When it is Mono/Apache stack, not an IIS. Then manual restarts can be the only workaround. In IIS the stale effects are naturally cleared in between periods of inactivity, when server kills idle processes. In Mono, there may or may not be same cleaning schedule, so, the process lifecycle and configs are the first place to look at for fix.
The behavior of not recompiling is caused by complex identity of requested pages. Identity includes URL, timestamp and session. If you trying to refresh page without closing the browser, then ASP server will need to serve a stale copy of older compiled page, because server tries to maintain consistency of served page with existing session, viewstate, perhaps even client side scripts wich exist on client in between partial updates, etc. Also browsers are designed to comply to slowly changed internet pages with storing copies in cache and maintaining the age of copies to skip unnecessary network trips. Or else internet would be 10 times slower.
Other note: The most slow files to push through ASP server are css files.
We're using an MVC-based plugin architecture using ASPX pages (because Razor ones need to be precompilated). Thus we're using a custom AssemblyResourceProvider to get the custom streams for the pages.
The problem comes when we try to load a Silverlight Application on the ASPX page that's on the same assembly as the page, as an embedded resource (because we want a full plugin architecture, a single dll should be enough for everything). Even with using a physical .XAP we can't get it to work, we suppose that as the path of the page is virtual, it won't be able to search the file thus generating a 2104 silverlight error.
We can use a http uri to get the .xap, and it'll be out last resort, but we'd like to do something similar as creating a custom AssemblyResourceProvider for ASPX pages and getting the stream from the assembly.
Is that even possible?
I'm not sure if this is a Sitecore 6 or Asp.net problem.
I have an assembly made up entirely of ascx user controls in which all of the necessary files are embedded resources (ascx, javascript, etc). I have been using the user controls in this assembly in a Sitecore web site for a few months.
Recently I tried to make changes to some of the user controls. I'm sure I made changes to the user controls in the past and it worked fine. But now when I make any changes to the ascx files they don't get picked up in the website. Changes to other files, including the code behind and javascript files are getting picked up. It appears only to be the ascx files that have a problem. It continues to use the old versions of the ascx files, from where I have no idea.
I know it's using the latest version of my assembly because I've stepped through the code behind, and used Fusion to check where the assemblies are loaded from. I've tried deleting all of the files in the Asp.Net cache. I've looked at the ascx files inside the assembly using a decompiler and it does have all of the changes I made. I turned off all caching in Sitecore just to see if that would fix it, but it didn't. I can't think of anything else to check. Any ideas?
Seems there is a new flag in web.config compilation settings called optimizeCompilations that is supposed to make things compile faster. Someone set this to true and that caused changes to user controls in other assemblies to not get compiled
I'm not sure how to test this question. I have an ASP.NET page for which performance is a big issue. At the same time, most of the content is static. In fact, all of the content is static at the moment. The content resides within a file extension of .aspx.
I am considering adding some functionality that would require dynamic code on the server side.
My question is, if a .aspx page does not contain any server-side code or runat="server" attributes, does anything .NET related get started? Alternatively, if a single line of server code were added to a Page_Load event handler, would this introduce a bunch of overhead like starting up the .NET runtime and such? How big of a performance penalty is it to add server code?
Thank you,
If you have a .Net application pool (and if you're serving .aspx pages, you do), the ASP.Net processor has to start up and compile the app before the first request to your page by any user. So any startup code you're worried about is already running.
If you already has .aspx pages, then you are already executing ASP .NET, and the pages are getting compiled in the background.
In that case, there will be no performance penalty in adding code, other than executing the code in question, of course.
Why don't you try it and benchmark it? An aspx page with "static" content will still get compiled. If performance is an issue, you can consider caching if appropriate.