A variety of issues and pitfalls face software developers every day. The focus of this article will be, however, on issues encountered when developing ASP.NET applications. .NET development can be rewarding for developers who understand the framework well, but if they lack the proper training or don't have enough experience with the framework, .NET development can be intimidating.
If your web.config file is left untouched, you will have the default “Event Log” items logged. It is very important that you view all errors. If you fail to notice errors, your ASP.NET application development endeavors will fail due to slow load times.
ASP.NET application hanging is another notorious problem. Your IIS website will either take some time to load or it will simply return an HTTP error code in the "500" series. The two types of hangs that you need to avoid when developing .NET applications are "soft hangs" and "hard hangs".
When bad code is found in parts of the website that are not its core, a "soft hang" can occur. There is no way to load sections of pages or entire pages with them. Even if Visual Studio or your preferred IDE shows no compile or run-time errors, it is important to follow code review and peer testing methods.
The "hard hang" is very dangerous. It occurs when your software stops working completely due to bad code. If a single bracket is forgotten, tokenized values can be corrupted. You should ensure that proper testing and code review takes place in order to avoid this type of issue.
Another issue that .NET developers face is server overload. The IIS suite includes a number of tools, including the "IIS Server.".
It may be easier to host an ASP.NET application as the user base grows, but without load balancing, many servers will eventually become overburdened. In addition to resource overutilization, other factors may also play a role.
Almost any problem with the IIS server can cause this error. In order to cause this issue, you only need to use an SSL certificate that has been placed on the CRL or has expired. Developers should also test their ASP.NET code and the application layer before they put them into production, as application pooling and caching problems may also contribute to the issue.
Although developers are free to use any database technology they choose for ASP.NET applications, it is often the case that they choose Microsoft's SQL Server database manager since it "fits" best with ASP.NET. During the development process, database issues are one of the biggest challenges you will face. There's a good chance that a database issue is causing the slow performance of a web page. I believe that it is important to check with the database administrator before pointing fingers at developers, and monitor how long common database queries take to complete.
A large database and complex operations on it can easily delay the loading of an ASP.NET page by seconds (or even minutes, in unfortunate cases). There can also be problems with the database configuration. The developer may or may not have control over how database calls and the database schema work, depending on how your app development team is organized.
Net Developmental Issues & advice how to avoid mistakes
In different contexts, implement different queries in the database. If you're going to use an API or a website, you will probably require a different set of entity properties, so don't load anything that isn't needed just because it's convenient to reuse the query.
We suggest you download MiniProfiler and configure it so that it runs every time you hit your site (don't enable it for the public to see). A big red warning will appear when the same database query is run more than once and you will get a detailed execution time.
Make sure paging is conducted at the database layer
If you want to use grid controls (framework based or 3rd party owned), you should carefully consider how it is implemented in terms of paging.
There are many controls that implement paging in a simplistic manner, when the database is accessed using a drop-down menu. All available data must be returned, and the control limits what can be displayed. Performance issues arise from this strategy, since it means that all the data from a given set must be extracted from the database (for example, all customers or orders). Accordingly, it could result in significant performance issues.
When validating on the client, the user experience will be snappier
Validate form entries on the client before posting them to avoid unnecessary round trips to the server. The application will feel more responsive and you will receive quicker feedback.
You should also make sure to provide explanations for any errors you find during validation. Use a message explaining what the rules are if you are using complex password rules or regex patterns to prevent users from becoming frustrated.
Always perform validation on the server as well
In spite of the title, this isn't quite a performance tip, but rather a security tip for when people think they could improve performance by cutting out server-side validation from the application. Today, client-side validation can be bypassed with ease, so you can't rely on the information coming from your browser to be accurate. As a result, if you think you can save some processing cycles and bypass these steps, you should not do so, as this opens up massive security holes.
It is not uncommon for many ASP.NET projects to include client script libraries that are ready to use, but you may or may not be using them. Checking what you are using, and when, is always a good idea.
The "using" statement dramatically reduces memory leaks
The use of a type that implements IDisposable should be wrapped in a "using" statement, so that it will automatically dispose of objects when the block ends.
Avoid running sites in debug mode
One of the most common performance blunders I see with ASP.NET is running sites in debug mode accidentally or intentionally. There are many optimizations one can do at the language level, like using StringBuilders instead of Lists, Switch instead of If-Then-Else, and so on, but what is surprising is that they pale in comparison to optimizations one could make at the framework level.
When in production, carefully consider what you need to log
The configuration of logging is often overlooked when deploying to production. If you intend to have logging on by default, you should determine which level to target if it is on or off by default. Moreover, you should check to which targets you are sending data, what archive strategy you have in place, and whether you are using async logging.
A selection of tips
Your page will load faster if you include the height and width in the *img /> tags, as space can be allocated before the image is downloaded. Asynchronous downloads halt when a script reference is reached, so place script references at the bottom of the page. You can also download images and style sheets asynchronously.
Hosting images and scripts on a content delivery network (CDN) is a good solution. These images and scripts will be cached and the load on your server will be reduced. Use image sprites to download smaller images at one time.
AJAX can be used to retrieve components asynchronously that may not be required immediately, such as the content of a collapsed panel, content behind a tab, and so on and so on. Remove any HTTP modules that aren't being used (Windows authentication, for example), and disable any services that aren't being used, such as FTP and SMTP.
Use the startMode attribute to reduce the load time for your ASP.NET site
When you update your website, IIS must recompile it during the first request, as a result, the first request takes considerably longer than subsequent ones. As part of the update process, you can tell IIS to automatically recompile your site as part of the update process. The startMode attribute in the ApplicationHost.config file can be used to specify this. There is even the ability to specify a custom action to be executed at startup, such as pre-populating a data cache.
If you are attempting to solve performance problems, do not underestimate the importance of the user interface
User interface tricks, such as progress bars, redirecting users' attention with animations, or placing slower loading sections at the bottom of a page or off-screen. By tuning the screen, you can often solve a performance problem without having to tweak the underlying code.
You should consider adding these UI tricks to your performance tuning toolbox because they can provide you with much quicker, easier results than addressing the underlying issues. You can use them as a holdover until you have the time to devote to tackling the core issue at hand.
Hardware should be thrown at the problem, not developers
Developers are often anxious to fix a problem with their code, but don't be afraid to "put down the compiler" and throw some hardware at the problem.
Many performance problems can be solved by purchasing a faster hard drive and/or more RAM in order to solve disk I/O bottlenecks or paging out of RAM problems. CPU-bound bottlenecks can often be solved by replacing the existing machine with a new one with a faster processor. Even though it sounds counterintuitive, purchasing a new machine or upgrading an aging one is often less expensive than having a developer troubleshoot, diagnose, and correct a deep performance problem.
As a bonus, the rest of your site will also receive a performance boost.
Don't assume that business logic is the only cause of problems
Often, we assume the problem is with our business logic when diagnosing performance problems. You must not forget the fact that the parts of our code that provide infrastructure can also cause problems.
HttpHandlers, HtmlHelpers, mappings, loggings, and IoC frameworks are increasingly at the root of performance problems. It is true that business logic still causes a fair share of problems when it comes to performance but infrastructure code is rapidly gaining ground when it comes to performance.
Verify that the problem is not related to the client before tackling any website performance issue
It is important to make sure a static collection only contains the objects you require. There is the possibility that when the collection is iterated over frequently, the performance can be slow if unnecessary objects are not removed. The objects contained within a collection will be kept in memory even after they have been disposed of, which can also cause a memory leak.
Avoid using session state
Whenever possible, you should try to avoid using session state whenever possible. Performance will not be a problem as long as you are using just one web server. The situation changes when scaling to multiple servers, as different, and usually slower, techniques are required.
Take advantage of the async constructs of .NET 4.5
Now that .NET 4.5 has been released, it has never been easier to write async code correctly. As with any tool, you should only apply it where it makes sense - in web use-cases, this usually refers to I/O operations (e.g. reading from disk, networking, using databases, or using web services).
Tony Moorer, Julie Beller, and Gregory Moorer offer ORM tips
More and more people are using Object to Relational Mapping (ORM) tools to bridge the gap between object-oriented application code and a relational database. ORM tools are excellent and dramatically improve development speed. However, there are a few things to be aware of.
You shouldn't follow the 'Hello World' examples provided with your ORM tool, as this turns it into an Object to Object Mapping. A database is different from an object. A relational storage engine such as SQL Server should still have a relational storage design.
When it comes to performance and memory management, parameterized queries are exactly the same as stored procedures.
As most ORM tools can either use stored procedures or parameterized queries, ensure that you are coding to these constructs and not hard-coding values into your T-SQL queries.
With the ORM tool you are able to create Create, Read, Update, and Delete (CRUD) queries with no need for a developer to intervene. Nevertheless, Read queries are often very inefficient. If you have a complex Read query, you might consider writing a stored procedure.
Since the code generated from the ORM is often ad hoc, make sure Optimize for Ad Hoc is enabled on the SQL Server instance.
The first time a query is passed, instead of storing a full plan in memory, a stub will be stored in memory. Memory management can be improved by this.
Check that the parameter size you are generating is the same as the data type defined within the database table. Most ORM tools size parameters in this way.
Passing a value of a certain size. This can lead to serious performance problems.
Database Performance Tips for Developers
As a developer, you may be expected to write queries, design tables and indexes, or even assist in determining how tables and indexes are configured in SQL Server systems. If you decide to move, these tips should make the process as painless as possible.
You will be able to generate a large portion of the code, but you will need to write at least some manually. It is important to remember the following tips to help you avoid problems in T-SQL programming if you are writing some or all of your code manually.
Although SELECT * is not necessarily bad, you should move only the data you need, and only when you need it, to minimize congestion across your network, disk drive, and memory.
In the case of small sets of data that are updated infrequently, such as lookup values, build a method to capture them in memory on your application server instead of constantly querying the database. Make sure that the variables and parameters you are using are of the same data type as the columns you are using. If you convert the variables to a different data type, the performance of the query will be affected.
The process of indexing tables is not a precise science. It takes a bit of trial and error combined with a great deal of testing to get things just right. Even then, as you continue to add more and more data, you will find the performance metrics changing over time.
It is possible to have exactly one clustered index per table. Make sure it is located correctly. If the most frequently accessed column is not a primary key, a second choice may be the most frequently accessed column. As a second choice, there is the possibility of structuring the storage in such a way that helps improve performance. This is essential for data partitioning.
Performance is improved when indexes are placed on columns used in WHERE, JOIN, ORDER BY, GROUP, and TOP. Confirm that the index is indeed improving performance.
Developers commonly use .NET Development because of its great toolchain. To be successful in the world of ASP.NET, you must know what to troubleshoot and how to troubleshoot. You may quickly become overwhelmed with the challenges involved if you don't have experts on your team.
In the field of compliant database operational automation, BitsOrchestra is a leading provider of software solutions. We specialize in database-driven applications over 5 years. 91% of Fortune 100 companies use our products, from small businesses to large corporations. Using our solutions, development teams, operations teams, and IT leaders can deliver software at speed and solve database challenges.
Are you looking for an opportunity to work with the Top 1% of IT talent on the market as well as access a world-class software development team? Our technical expertise and cross-industry experience allow us to transform digital transformation into digital acceleration. Ultimately, we strive to create lasting value throughout the entire digital transformation process. BitsOrchestra helps you identify the ideal match to your search criteria to get the subject matter expert you need on your team if you are looking for deep expertise in a particular technology, profile, or end-to-end solution.