We have migrated one classic ASP application to ASP.net2010 using C#.
Compare to the classic ASP application the newly migrated application's performance is bit slow.
Which areas need to be checked to improve performance?
Disable viewstate on pages and or controls that don't need it and follow all the advice given here: ASP.NET: how to load page faster
Run a profiler on it. I use JetBrain's. It will pin point the places in code that are the slowest.
Check your data access. In conversions like this, I've seen that as the major area of issue.
Page.IsPostBack Property
Enable Buffering
Remove unused HttpModules
Trim Page Sizes
Use a CDN
Server.Transfer and Response.Redirect
Precompiling
Session State Management
ViewState
Caching
Locking and Shared Resources
this post explains a 20 tips to improve asp.net performance
mainly you will find tips like reduce usage of sessions and ViewState.. keep page size small
don't include any css styles or javascripts in the page markup.
please go through below links. And implement based on your need.
http://wiki.asp.net/page.aspx/667/improve-perfomance-in-aspnet/
http://madskristensen.net/post/A-whitespace-removal-HTTP-module-for-ASPNET-20.aspx
http://madskristensen.net/post/HTTP-compression-in-ASPNET-20.aspx
http://weblogs.asp.net/owscott/archive/2004/01/12/IIS-Compression-in-IIS6.0.aspx
http://it.megocollector.com/?p=1258http://weblogs.asp.net/lkempe/archive/2010/01/03/optimization-of-web-site-hosted-on-iis-6.aspx
http://developer.yahoo.com/performance/rules.html
http://omaralzabir.com/best_practices_for_creating_websites_in_iis_6_0/
http://www.c-sharpcorner.com/uploadfile/shivprasadk/net-best-practice-no-1-detecting-high-memory-consuming-functions-in-net-code/
Related
To be more specific... When someone clicks a link on my web application, can that user be redirected immediately after the click and then wait for the page (user controls) to load. (Can the user controls load one by one with a priority or something?)
Right know, there is a delay after the user clicks on a link and then gets redirected.
Things you can do:
Check how you're using the ViewState if you're not careful it gets
quite big. But some parts of your app might be depending on it so
it's kind of situational.
Caching of pages or just controls
AJAX - while it doesn't feel as natural as in the MVC, it's still an option
for Web Forms
Script & Css bundling and minification - less requests
for more data are always faster then more requests for less data
These are things I'd start with. From my experience excesive ViewState is the place where you can gain the most but a usually it takes quite some effort to get rid of it since just turning it off might make some of your controls not working properly on postback.
This is just a start but going deeper would require much deeper knowladge of the application.
You could use AJAX technology to create the required responsiveness of your application.
In fact, you only need one page. You could load all actions performed (and the updated HTML/JS) using AJAX.
I would advise to read into that subject. You could use jQuery or similar frameworks to do the communication with the web server.
Required reading: ASP.NET AJAX.
My advice is to try to redo your application with AJAX approach:
here is a smart article about it http://www.asp.net/mvc/overview/older-versions-1/nerddinner/use-ajax-to-deliver-dynamic-updates
Take a look to AJAX technique: http://en.wikipedia.org/wiki/Ajax_(programming)
From what I understand, you are using classic Asp.NET and therefore, webforms.
One way to speed things would be to switch to the Razor platform, which eases things a bit (by preventing unnecessary postbacks).
Alternatively, if you don't want to remake the whole application, you could use a simple html link instead of an asp:hyperlink.
i use visual studio 2012 to make websites now since i like the IDE.I want to know that if there is any performance difference between a static html website and a website in asp.net without dynamic controls...
thanks.
Most of the time waiting for a web page to load is the network latency. Hardly any of it is latency due to the server dynamically generating the page (assuming the code isn't really bad). So the answer is, no, there is no noticeable difference to load time between static and dynamic pages.
Dynamic pages are mostly connected to a database server. So your app should query the database and fetch data, then manipulate the data and render as html page as output.
So html pages don’t need those steps therefore html pages are always faster than any dynamic pages (not only for asp.net but also other languages).
Is there a way to programmatically prime the asp.net output cache? I've investigated the caching API and can't seem to find an obvious way to do this. Has anyone tried something like this? If so, what method did you use?
I gave some thought to this last year and ended up concluding that it was not that important for the case, but if it's important for you website, all you have to do is to simply call the webpages from somewhere like Application_Start (after all code has run) event but you shouldn't stop there!
The cache will eventually expire and to avoid that you should set up some way to cache the pages again before any clients requests that page.
Make the outputcache dependent on someother object in cache and set an expiration callback.
Thus, when that cache object expires, so does your pages and you should make http requests to the pages you want to recache and so on.
I'm answering to this question, but the amount of effort and question marks I still have in my mind lead me to advise not to go through with this...
UPDATE
The only kind of dependency you may set in outputcache is sql dependency. Use it if you want, but if you would need to depend your outputcache on some other business object, then this might get very difficult. I could tell you that you could set a database object and depend your database on it and expire it yourself using some kind of timer.
Man, the longer I write the more solutions and difficulties I find! I can't write a book for something that is not worthy your precious time. Believe me you that the usefulness for this will be nearly zero.
Priming the cache is as others have suggested as easy as requesting the pages you want cached. Of course if you do this programmaticly it will only request the HTML and not all the linked resources (CSS, JavaScript, Images...) which is a good thing to avoid wasted bandwidth.
For many websites the items that are cached which consume the biggest performance penalties are common to many or all pages. For example a navigation system on a large CMS or storefront may query the database and do a bunch of rendering work which can then be cached for all pages. Also a big part of the initial load in ASP.net is when the website if first accessed and loaded into memory. Both of these issues can be addressed by even calling a single page on your site, but there is nothing stopping you from making a list of URLs and calling each one periodically.
If your cache policy is set for a 20 minutes timeout, maybe request each page once every 17-18 minutes.
Here are some resources with source code to help you get started:
Good Simple Primer on requesting web URL in C#
Website Monitoring Windows Service
Asyncronous Website Monitor
As I mentioned before, you can easily extend these to "foreach" over an array or list of URLs to be requested.
From a security stand point what are a couple major points that would aid in the result of using a .master file versus a .aspx file?
From a security standpoint, there isn't really a difference in a .master file and a .aspx file. They do have a unique execution path when it comes to a page life cycle, but they are executed in the same way and would be prone to the same security flaws & protections.
That said, the reduction of code that a .master file allows (as well as forcing you to think about generaliation) will go a long way in helping you develope a reliable (related to security) website.
Technically, there's no major difference from a security standpoint. You could implement your security logic from within the Master page, which would insure that it's included on every page that uses that MasterPage. You could argue this makes things more secure because there is less chance for human error :).
Both master and content page make up 1 rendered page in your browser. The master page is there to create a common look and feel throughout your entire site, or parts of it. You can even nest master pages if needed.
ASP.NET as a whole already has quite some security hooks built in by default. RequestValidation to prevent malicious input, parametrized queries are possible to prevent SQL injection, Membership for authentication, Roles for authorization, UrlAuthorization to prevent people of guessing urls and might be able to see sensitive data, ...
Be sure to also check out patterns & practices Security How Tos Index.
Its a trick homework question -- neither should have anything to do with security.
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.