.NET Performance Comparisons and Techniques
Performance Comparison: Data Access Techniques OR MSDN Search: Performance Comparison: Data Access Techniques
DataReader is the best when Forward Read-Only access to data is required.
DataSets are useful when you need the data, schema and maybe updateable options.
The new DataSet is .NET 2.0 also does away with the problem of using a DataSetSurrogate in .NET 1.1 as 1.1 datasets are transmitted in xml across remoting boundaries which is costly for a binary remoting approach.
Performance Comparison: .NET Remoting vs. ASP.NET Web Services
If your application needs interoperability with other platforms or operating systems, you would be better off using ASP.NET Web services, as they are more flexible in that they support SOAP section 5 and Document/Literal. On the other hand, use .NET Remoting when you need the richer object-oriented programming model. See ASP.NET Web Services or .NET Remoting: How to Choose for details. In scenarios where performance is the main requirement with security and process lifecycle management is not a major concern, .NET Remoting TCP/Binary is a viable option; however, keep in mind that you can increase the performance of IIS-hosted implementations by adding a few more machines into the system, which may not be possible when using a .NET Remoting TCP/Binary implementation.
Performance Comparison: Encryption Techniques -- Security Choices
When designing a secure system, the implementation techniques should be chosen based on threat mitigation first and performance second. For instance, basic authentication without SSL could be used for better performance, but no matter how fast it is, it would not be useful in systems that are vulnerable to threats not mitigated by it.
Performance Comparison: Transaction Control
Running a database transaction implemented in a stored procedure offers the best performance because it needs only a single round trip to the database
Improving ASP.NET Performance
Application_BeginRequest:
This event is used when a client makes a request for any ASP.NET web page/handler. It can be useful for redirecting or validating a page request.
So, the ValidateToken call should be done here. Since the handler (s) will have similar headers this validation logic would be moved to a common area, called on every postback.
Application_Error:
This event is used to handle all unhandled exceptions for any ASP.NET web page/handler. So, all ASP.NET global web errors would have to be trapped here. Alwways, implement a Global.asax error handler. Monitor application exceptions. Use try/finally on disposable resources. Write code that avoids exceptions.
Application_AuthenticateRequest:This event occurs when the identity of the current user has been established as valid by the security module(NT/Forms authentication) and is available for custom validation, called on every postback.
Exception Logging:
This event is used when a client makes a request for any ASP.NET web page/handler. It can be useful for redirecting or validating a page request.
So, the ValidateToken call should be done here. Since the handler (s) will have similar headers this validation logic would be moved to a common area.
Response.Flush and Buffer=true behaviour
Microsoft admits that the response.flush waits for the client browser to acknowledge the flush before continuing to process the ASP code. One a very fast internet connection, you don't notice the problem, but a slower modem takes longer to perform that task, and therefore a flush can be bad. So use response.buffer=true, of course but remove or restrict all response.flush commands from the site, and see an instant and dramatic speed improvement for modem connected clients. The acknowledgements from the client occur after the client receives all the content from the server on a flush.
Do not generate user interfaces within global.asax – No Response.Write()'s
Suppress the internal call to Response.End. The Server.Transfer, Response.Redirect, Response.End methods all raise exceptions. Each of these methods internally call Response.End. The call to Response.End, in turn, causes a ThreadAbortException exception. If you use Response.Redirect, consider using the overloaded method and passing false as the second parameter to suppress the internal call to Response.End.
Inefficient rendering. Interspersing HTML and server code, performing unnecessary initialization code on page postback, and late-bound data binding may all cause significant rendering overhead. This may decrease the perceived and true page performance.
Avoid showing too much exception detail to users. Avoid displaying detailed exception information to users, to help maintain security and to reduce the amount of data that is sent to the client.
The following guidelines relate to the development of individual .aspx and .ascx Web page files.
· Trim your page size. (Reduce/Disable ViewState usage, use a common css file, use use script language="jscript" src="scripts\myscript.js", remove extra white spaces in tables etc eg.
· Enable buffering. in a page or
· Use Page.IsPostBack to minimize redundant processing.
· Partition page content to improve caching efficiency and reduce rendering.
· Ensure pages are batch compiled.
· Ensure debug is set to false. in a page or in web.config
· Optimize expensive loops. Use For instead of ForEach in performance-critical code paths.
· Consider using Server.Transfer instead of Response.Redirect.
· Use client-side validation. reduce the round trips
Avoid Using Page.DataBind Calling Page.DataBind invokes the page-level method. The page-level method in turn calls the
DataBind method of every control on the page that supports data binding. Instead of calling the page-level DataBind, call
DataBind on specific controls.
The following line calls the page level DataBind. The page level DataBind in turn recursively calls DataBind on each control.
Avoid DataBind();
The following line calls DataBind on the specific control.
yourServerControl.DataBind();
Minimize Calls to DataBinder.Eval
The DataBinder.Eval method uses reflection to evaluate the arguments that are passed in and to return the results. If you have a table that has 100 rows and 10 columns, you call DataBinder.Eval 1,000 times if you use DataBinder.Eval on each column
Use explicit casting. Using explicit casting (eg. in templates) offers better performance by avoiding the cost of reflection. eg. ((DataRowView)Container.DataItem)["field1"]
Use the ItemDataBound event. If the record that is being data bound contains many fields, it may be more efficient to use the ItemDataBound event. By using this event, you only perform the type conversion once.eg. protected void Repeater_ItemDataBound(Object sender, RepeaterItemEventArgs e) { ... }
State Management
· Application state. Application state is used for storing application-wide state for all clients. Using application state affects scalability because it causes server affinity.
Application["YourGlobalState"] = somevalue;
Use static properties instead of the Application object to store application state. Use application state to share static, read-only data.
· Session state. Session state is used for storing per-user state on the server. The state information is tracked by using a session cookie or a mangled URL. ASP.NET session state scales across Web servers in a farm. (options:InProc, StateService, SQL Server). Disable if not needed
· View state. View state is used for storing per-page state information. The state flows with every HTTP POST request and response. Think of serializatrion costs. Disable if not needed
· Alternatives. Other techniques for state management include client cookies, query strings, and hidden form fields.
PS: Store simple state on the client where possible. Consider serialization costs.
Short Circuit the HTTP Pipeline
The HTTP pipeline sequence is determined by settings in the Machine.config file. Put the modules that you do not use inside comments. For example, if you do not
use Forms authentication, you should explicitly remove the entry in your Web.config file for a particular application using remove tag.
Use Response.Write for formatting output. Use StringBuilder for temporary buffers. Use HtmlTextWriter when building custom controls. Avoid strings for concatenation, using StringBuilder
Data Access
· Use paging for large result sets.
· Use a DataReader for fast and efficient data binding.
· Prevent users from requesting too much data.
· Consider caching data. (Invalidate cache when appropriate)
HttpModule—the Filter for all Requests The HttpModule does not replace the target of a request, however the HttpModule receives notification at various processing points during the lifespan of a request. Since (as is the case with HttpHandlers) we can map an HttpModule to all application request pages we can use an HttpModule as the foundation for a web application controller.The HttpModule class is accessible via any thread which happens to be serving the current request. Since access to the HttpModule doesn't require a specific thread, the single class instance doesn't represent a bottleneck.
IHttpHandler.IsReusable()
By calling IsReusable, an HTTP factory can query a handler to determine whether the same instance can be used to service multiple requests. [ PS: ASP.NET uses a pool of handlers to service requests. ]
No comments:
Post a Comment