I'm gradually building quite a complex project.
In the process of which I am also learning ASP.NET which I am new to.
Consequently, having experimented with various plugins (ASP.NET AJAX, JSON.NET) and found that in fact I didn't need them, my web.config file has become rather full up with lines added by Visual Studio, which in fact aren't used.
Since they've been automatically added and I am new to ASP.NET I am not sure which lines can be removed and which can't (some are more obvious than others of course)
So I was wondering what performance affect, if any, these extra lines, which may refer to unused plugin, will have.
Just for example, I have decided to stick entirely with jQuery for all my AJAX requirements. If I were to leave the AJAX.NET code lines in the web.config file (and the .dlls in my bin folder) will this affect performance, or is none of this loaded unless requested?
(if it makes any difference, I am coding with VB, not C#)
The web.config data is cached when an application first starts. Changes to the web.config will make your app restart.
So extra lines won't give you any performance problems because it's only loaded once.
However, if you refer to any unused HttpModules in your web.config this could reduce performance (Check tip 3 at 50 Tips to Boost ASP.NET Performance). You should remove them to make sure they don't run each request.
Related
I'm reviewing the way my company deploys websites and trying to determine if we need to update our methods. My particular question is geared towards the way we handle the web.config file. Currently, when we deploy, we do not override the web.config file that's on the server. We manually reproduce whatever changes were made during development. The reason is
1) we do not want to give developers the responsibility of remembering to deploy the right web.config (the production one) to the server during deployment
2) we also don't want to run the risk of anyone on the dev team accidentally changing (or even unnecessarily seeing) the production web.config
3) on some projects, there are other teams that have the power to modify the web.config (like connection string settings) and we don't want to override their changes
I've come across web.config transformations but it seems that our current methods are a better fit for our particular circumstance. I'm hoping for someone to give me a fresh perspective and probably help me see a better way if there indeed is one.
In a team of developers (i.e. UI designers, programmers, SQL developers), your strategy seems pretty right but it needs accurate co-ordination. The other way you can go is to tell all your departments about various parts of the web.config and the part which they are concerned with. Also, do commenting in the web.config file telling which parts are concerned with which team. This way they can handle the config file on their own by not fiddling with the parts they aren't concerned with.
You can also take help of VCS (version control systems) to keep track of what changes are made at what time and by which users.
We have a Webforms application that stores a bunch of settings and terminology mappings (several hundred) that are used throughout the application.
http://www.dotnetperls.com/global-variables-aspnet makes these assertions:
The Application[] collection .... may be slower and harder to deal with.
the Application[] object ...is inefficient in ASP.NET.
Is this recommended? Yes, and not just by the writer of this article. It is noted in Professional ASP.NET by Apress and many sites on the Internet. It works well
So I am wondering if these statements are true. Can anyone elaborate on why using Application is slower or what kind of problems can crop up if you use Application? I am sort of assuming that any problems or slowdowns might only surface under production loads, so that is why I am asking for real world experience, rather than just benchmarking myself.
I am aware that there are many alternatives to caching (HttpRuntime.Cache, memcached, etc) but specifically I want to know if I need to go back and rewrite my legacy code that uses Application[]. Specifically if in any way I am incurring a performance penalty I would want to get rid of that.
How are you saving these settings? I would recommend the web.config
If you're using the web.config to store these settings (if they're application variables that's a solid place to start), then no need for Application variables.
I try to steer clear of the Application level variables because they are way more expensive than Session variables.
Also, variables in the web.config / app.config files can change without having to change code and/or recompile your project.
Application class (global variables) only exist in ASP.NET to help with backwards compatibility with classic ASP, you could say it's deprecated.
Another thing you could look into would be caching your settings so you're not always reading from disk.
I've been working on a legacy ASP.NET Web Site (versus a Web Application) project at a client for some time now, and its slow compile time has me wondering:
Are web site projects known to be slow(er) at compiling (than Web Application projects)?
It's a pretty small website, but the entire solution has tons of functionality -- 19 projects worth of it, 18 of which compile really quickly (the non-web projects). The website project itself has ~100 pages and ~15 user controls (these actually take about half of the compile time) and normally compiles within 30 to 60 seconds. A complete re-build takes closer to the latter.
So, some things I believe could be slowing it down (you debunk them):
(X)HTML validation issues (the code we inherited has thousands of compiler warnings about validation issues).
High levels of abstraction -- since the code for the website pages is compiled at run-time, I'm guessing that whatever it's doing for user controls up-front is a lengthy process so that the binding at compile-time can happen.
The mere size of the web site? I know these are not very efficient projects, and believe me, I've spent hours trying to get it converted to a web application, but Visual Studio was unable to parse a single ASPX file into its .aspx/.designer.xx components because of the validation problems I mentioned earlier.
Assuming my client won't approve more than a few hours to fix this up, is there any quick fixes, changes, or optimizations known that could help me out?
I do not have a puny computer, so its processing power is not an issue. I've also worked on Web Application projects equivalent in size and complexity that compile in just a few seconds.
I'm open to pretty much anything, so I'd love to hear your thoughts! Also, if you think this should be a wiki, let me know.
My observations have been the same: web site projects take awhile to build, longer then web app projects. I think I found some information on why, check this out: http://msdn.microsoft.com/en-us/library/aa730880(VS.80).aspx
Search for "Iterative development". It says this about web site projects, when compared to web application projects:
By default, Visual Studio completely
compiles Web site projects whenever
you run or debug any page. This is
done to identify compile-time errors
anywhere in the site. However, a
complete site build can significantly
slow down the iterative development
process, so it is generally
recommended that you change the build
project option to compile only the
current page on run or debug.
First read this blog post Tips to optimize design-time build performance for Web Sites in Visual Studio 2005
Main points made:
Do not disable batch compilation
Leverage Server-side Compilation
Move App_Code files into a separate class library project
Check for conflicting dependencies
Turn off AutoToolboxPopulate in the Windows Forms Designer options.
Disable validation for HTML editing
Another option that could help you is switching to a RAM disk: Running development from a RAM disk – options and products
If that doesn't help maybe splitting your large WAP into multiple ones could improve compile time. Unfortunatelly that strategy requires you to drop developing on Cassini. Instead you will have to use IIS as host: Using multiple Web Application Projects (WAP) in one Solution
One fact most developers overlook in an ASP.NET Web Project is the amount of classes in the App_Code folder.
The more classes you put in it, the longer it will be the compilation time.
From the ASP.NET Compilation Overview on MSDN:
ASP.NET creates an assembly for each
application directory (such as
App_Code) and one for the main
directory. (If files in a directory
are in different programming
languages, then separate assemblies
will be created for each language.)
So, if you can basically minimize the Folder Hierarchy and reduce the amount of classes in it, it will probably reduce the compilation time.
Another thing I noticed from your post is that, you have 18 non-website projects.
I think it is a bit too excessive because think of it this way.
When the Web Project compilation starts, the ASP.NET Compiler needs to link the 18 separate DLL files.
If those projects can be combined to reduce the number of DLLs, it might help also.
From maintainability viewpoint, having 18 projects is a bit excessive unless there are REAL strong reasons to do so.
I would suggest reviewing the projects and combine them.
I hope it helps.
This may not be ideal, but you can split your projects into multiple solutions. For example you can take the user controls and put them in Solution A and the rest of projects into Solution B. Then compile the controls in Solution A and file reference to them from Solution B which should help cut down the compile time
Website or web project, the performance should be similar after compilation phase. If the issue is poor performance immediately after deploying a new set of codes, a quick way I can think of is to pre-publish the site. (see reference http://msdn.microsoft.com/en-us/library/1y1404zt(VS.80).aspx)
Depending on the options you choose during the publishing, you may lack flexibility to make changes on the fly (which you shouldn't anyway).
Obviously having whitespace in css, aspx and html pages is a great advantage at design time. But is there a way to (a tool that will) clear all the whitespace from all the files and possibly merge javascript and css files in a more optimal way.
I am using asp.net themes so there are quite a lot of separate css files that would be improved through some form of automated combining. I have seen a few http modules but that isn't quite what I want I just want to run something over the published project beofre sending it to the server.
EDIT: Compression at least in IIS is unfortunately not an option, we are currently running it on the same IIS server as a third party web based student management system. It doesn't like compression and the IIS options don't seem to be per application pool. I did apply asp.net compression but the bulk of my extra data seems to be the app_themes which I know would compress well I just don't want to have to manually go through compressing all the css separately.
An empirical study on the effect of removing white space from a not-untypical website (Drupal) showed minimal effects. (site also contains some links to non .net html white space removal tools)
I have gotten magical improvements in page size by aggressively managing viewstate size and using Blowery's http compression module.
Another strategy is to do minifiation (merging many css files into one). Telerik has such a component RadStyleSheetManager, it works only with style sheets embedded into assemblies.
There is another way
http://omari-o.blogspot.com/2009/09/aspnet-white-space-cleaning-with-no.html
I think one of the reasons that this was never included in .NET was because they expected you to turn on server compression in these scenarios. IMO I don't agree with this -- I think it's a shame that at least aspnet_compiler.exe can't do this optimization. It would be such a great performance boost on uncompressed connections. Anyway, you can enable compression on IIS 6:
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/d52ff289-94d3-4085-bc4e-24eb4f312e0e.mspx?mfr=true
And it's even easier and more flexible in IIS7 to do so. I hope someone has a better solution than I!
4 guys from Rolla just published an article on a http module that removes white space. You would need IIS 7 in integrated mode to make it work for css (or possibly IIS6 with wildcard mappings)
It looks more like a proof of concept, but the code is free.
i found this:
http://msdn.microsoft.com/en-us/library/aa719805(VS.71).aspx
greets!
What's the performance penalty on defining classes in an aspx/ascx codebehind rather than compiling them into a dll beforehand? I know that this isn't a best practice and that there are numerous problems with this (e.g. difficult to unit test, code is not reusable, etc.), but it does come in very handy when you're dealing with classes that need to be modified on the fly several times a day since those modifications will not require any sort of app restart (e.g. App_Code changes, updating dlls in bin folder).
"None." The codebehind classes are compiled into a DLL on the fly, and then that DLL is kept around. So basically the first time you load the page there will be a short delay, but afterwards the speed should be the same as with precompiled classes.
You should see no performance issue after the initial compile. It sounds as though you have business logic that is changing frequently, and not necessarily the web pages.
The choice of whether to use dynamic compilation or compiled DLLs really has to do with how organized your release process is. If your application is tightly compiled into DLLs than you can expect that you've tested for build errors and expect things to be more sturdy when you release. With dynamic compilation you have the ability to swap out .cs files on the fly (e.g. drag & drop, ftp). This means you may be more agile, but you might not have that extra step of assurance that helps you know you're keeping the build intact.
Collateral damage - session resets
From personal experience, users are much more likely to complain about session reset caused by App Domain recycling than about slight performance hit. So if you can shift your changes from code to data and avoid code updates altogether, by all means do it. This will improve your users' performance :)
I don't believe there really is a performance penalty after the initial dynamic compilation (which will occur on the first hit to the page whose code-behind was modified). How did you end up having to change classes several times a day? That would suck!
EDIT:
I should've added that this shouldn't affect unit tests or the code-reusability like you stated. There's nothing stopping you from deploying a non-pre-compiled site for maintainability purposes while still being able to run unit tests, deploying compiled assemblies for other projects (if needed), etc. during a check-in/build.
However, if you're not using source control and don't have an automated build, then there's a whole new problem. Our team members used to edit CODE files directly on production servers. shivers