Application Security Testing: An Integral Part of DevOps
When you design and develop your web application, you always must take into consideration the performance factor. By doing this, you will remove the cost of rewriting modules, modifying code, or redistributing the application. A good practice that must be kept in mind for writing quality code is to make frequent code reviews. For example, I often find a better implementation of a certain module after a code review. Also, you should test different ways of implementing your code to determine the performance impact over your application.
Here are some rules that should be followed for writing high performing applications.
Use Caching to Store Your Content
Avoid Session State
Whether you store your data in in-process, on a state server, or in a SQL database, session state requires memory; it's also time consuming when you store or retrieve data from it. If you do not want to use session state, disable it on your web form by using the <@%Page EnableSessionState="falseb"%> directive. In case you use the session state only to retrieve data from it and not to update it, make the session state read only by using the <@%Page EnableSessionState ="ReadOnly"%> directive.
ViewState allows you to keep the content of a control across trips to the server. This comes with a cost: A greater amount of data is sent from the server to client end vice versa, so the speed and network bandwidth can be affected. You can avoid this drawback by setting the EnableViewState property of your web controls to false when you don't need them to keep their state across server trips.
Use Low-Cost Authentication
Authentication also can have an impact over the performance of your application. For example, passport authentication is slower than form-base authentication, which in turn is slower than Windows authentication.
Use the Server.Transfer() Method for Server-Side Page Redirection
It is better to use the Server.Transfer() method for server-side ASPX page redirection in the same application than the Response.Redirect() method. This will reduce the extra roundtrip required by the second method (Response.Redirect()) to perform client-side redirection.
Reduce The Number of Web Server Controls
The use of web server controls increases your application's response time because they need time to be processed on the server side before they are rendered on the client side. Therefore, take in consideration the usage of HTML elements where they are suited; for example, if you want to display static text.
Avoid Frequent Usage of Boxing and Unboxing
When a value type, such as a structure, is copied to a reference type such as a class, the compiler creates an object on the heap and copies the value of the value type from the stack to this newly created object on the heap. This process is called boxing and requires more overhead than just a simple from value type to value type. When you copy a reference type to a value type, the value of the object from the heap is copied to the value type from the stack. This process is called unboxing. You should take in consideration the overhead of these processes when you design your application.
Avoid Using the String Type for Complex Strings Operations
The string type is immutable; this means that after a string is created it can't be modified. When you modify a string, the CRL creates a new string based on your modifications and returns it. The old string remains in memory until garbage collector clears it. If your application is extensively modifying strings, use the StringBuilder class. This class stores the string as an array of characters. The StringBuilder object is mutable and does in-place modifications of strings.
Use the AddRange() Method with Collections
There is a large number of collection classes that expose the AddRange() method. You can use this to add an array of items to the collection instead of calling the Add() method repeatedly inside a loop.
Avoid Throwing Exceptions
Throwing exceptions is a costly operation. You should be very careful when you throw an exception from your application. Exceptions should be thrown only to signify exceptional error cases. You should never throw exceptions just to manage your application flow.
Avoid Using Unmanaged Code
Calls to unmanaged code are a costly marshaling operation. Try to reduce the number of calls between the managed and unmanaged code. Consider doing more work in each call rather than making frequent calls to do small tasks.
Avoid Making Frequent Calls Across Processes
If you are working with distributed applications, this involves additional overhead negotiating network and application level protocols. In this case, network speed can also be a bottleneck. Try to do as much work as possible in fewer calls over the network.
Make Use of Optimized Managed Providers
As you know, OleDb is a generic provider that offers access to data exposed by any OleDb provider. Managed providers are specifically optimized for some databases. For example, when you use OleDb to connect to a SQL server database, OleDb first passes your request to the OLE DB COM components, which in turn translate the request to SQL Native Tabular Data Stream (TDS) format. Using SqlClient directly constructs the TDS packets and communicates with SQL server. The removal of the extra translation will significantly improve your application's performance.
Use Stored Procedures and Not SQL Statements
When you are working with a RDBMS as a SQL server, you should use stored procedures rather than SQL statements given as a text command because stored procedures are highly optimized for server-side data access.
Use DataReader Instead of DataSet for Forward-Only Sequential Access
If you are reading a table sequentially, you should use the DataReader rather than DataSet. The DataReader object creates a read-only stream of data that will increase your application performance because only one row is in memory at a time.
Use Connection Pooling
The slowest operation performed in a database application scenario is establishing a connection with a database. The SQL server .NET Data Provider offers connection pooling to improve performance when connecting to a SQL server database. In connection pooling, old connection information is stored in a connection pool so it can be re-used for the next connection. If you are using dynamic connection strings, you should disallow the connection pooling mechanism because connections are only pooled on the exact connection string.
Distributed transactions might add performance overhead to your application, so you should use them only when required and keep their life as short as possible.