#1: Too Many Database Calls
The problem we see the most are too many database query per request/transaction.

There are 3 specific phenomena to witness:

1. More data is requested is than actually required in the context of the current transaction, e.g.: requesting all account information instead of those that we need to display on the current screen.
2. The same data is requested multiple times. This usually happens when different components involved in the same transaction act independently from one another and each requests the same set of data. It is unknown what type of data has already been loaded in the current context so we end up with the same queries multiple times.
3. Multiple queries are executed to retrieve a certain set of data. This is often a result of not taken full advantage of complex SQL statements or stored procedures to retrieve the data in one batch.

Further Reading: Blog on Linq2Sql Performance Issues on Database,  Video on Performance Anti-Patterns

#2: Synchronized to Death
There is no question that synchronization is necessary to protect shared data in an application. Too often developers make the mistake to over-synchronize, e.g.: excessively-large code sequences are synchronized. Under low load (on the local developers workstation) performance won’t be a problem. In a high-load or production environment over-synchronization results in severe performance and scalability problems.

Further Reading: How to identify synchronization problems under load

#3: Too chatty on the remoting channels
Many libraries out there make remote communication seem like a piece of cake. There is hardly any difference for the developer to call a local vs. remote method. The lack of understanding of what is really going on under the remoting-hood makes people forget about things like latency, serialization, network traffic and memory usage that come with every remoting call. The easy way of using these technologies results in too many calls across these remoting boundaries and in the end causes performance and scalability problems.

Further Reading: Performance Considerations in Distributed Applications

#4: Wrong usage of O/R-Mappers
Object-Relational Mappers take a big burden off developers’ shoulders – loading and persisting objects in the database. As with any framework there usually are many configuration options to optimize the usage of the O/R Mapper for current application use cases. Faulty settings and incorrect usage of the framework itself too often results in unexpected performance and scalability problems within these frameworks. Make sure you make yourself familiar with all options and learn about the internals of these libraries that you rely on.

Further Reads: Understanding Hibernate Session Cache, Understanding the Query Cache, Understanding the Second Level Cache

#5: Memory Leaks
Managed runtime environments such as Java and .NET have the advantage of helping with memory management by offering Garbage Collectors. A GC, however, does not prevent memory leaks. Objects that are “forgotten” will stick around in memory and ultimately lead to a memory leak that may cause an OutOfMemoryException. It is important to release object references as soon as they are no longer needed.

Further Read: Understanding and finding Memory Leaks

#6: Problematic Third-Party Code/Components
Nobody is writing all of the functionality of a new application on their own. We use existing 3rd party libraries to speed up our development process. Not only do we speed up our output – but we also increase performance risks introduced by these components. Even though most frameworks are well documented and have been thoroughly tested, there is no guarantee that these frameworks run as expected in every use case they are included. 3rd party code is often used incorrectly or in ways that have not been tested. It is therefore important to make an in-depth check of every framework before introducing it into your code.

Further Read: Top SharePoint Performance Mistakes

#7: Wasteful handling of scarce resources
Resources such as memory, CPU, I/O or the database are scarce. Wasteful handling of these resources results in lack of access to these resources by others and ultimately leads to performance and scalability issues. A good example: database connections that are kept open for too long. Connections must only be used for the time period they are really needed, e.g.: for a query – and then returned to the connection pool. We often see that connections are requested early on in the request handler and are not released until the very end which leads to a classic bottleneck situation.

Further Read: Resource Leak detection in .NET Applications

#8: Bloated web front ends
Thanks to high-speed web access many users have a better end-user experience in the World Wide Web. The downside of this trend is that many applications get packed with too much stuff – they become bloated – which ultimately leads to bad browsing behavior. Particularly  users that do not yet have high-speed internet access suffer the most. Too many images that are too large; failure to use or incorrect usage of the browser cache; or overly-aggressive usage of JavaScript/AJAX – all result in performance problems in the browser. Following the existing Best Practices on Web Site Performance Optimization can solve most of these problems:

Further Read: How Better Caching would help speed up Frankfurt Airport Web Site

#9: Wrong Cache Strategy leads to excessive Garbage Collection
Caching objects in memory to avoid constant roundtrips to the database is one way to boost performance. Caching too many objects – or objects that are hardly ever used quickly changes the advantage of caching into a disadvantage due to higher memory usage and increased GC activity. Before implementing a caching strategy you have to figure out which objects to cache and which objects not to cache in order to avoid these types of performance and scalability problems:

Further Reads: Java Memory Problems, Identify GC Bottlenecks in Distributed Applications

#10: Intermittent Problems
Intermittent problems are hard to find. These are usually problems that occur with specific input parameters or only happen under certain load conditions. Full test coverage – functional as well as load and performance coverage – will uncover most of these problems early on before they become real problems for real users.

Further Reads: Tracing Intermittent Errors by Lucy Monahan from Novell, How to find invisible performance problems

(Bonus Problem) #11: Expensive Serialization
With remoting communication – such as Web Services, RMI or WCF – objects need to serialized by the caller in order to be transferred over the network. The callee on the other side needs to de-serialize the object before it can be used. Transformation therefore happens on both sides of the call resulting in some overhead while doing so. It is important to understand what type of serialization is required by both ends and what the optimal choice of serialization and transport type is. Different types of serialization have a different impact on performance, scalability, memory usage and network traffic.

Further Read: Performance Considerations in Distributed Applications

Strictly speaking, the DTO (Data Transfer Object) pattern was originally created for serializing and transmitting objects. But since then, DTOs have proven useful for things like commands, parameter objects, events, and as intermediary objects when mapping between different contexts (e.g. importing rows from an Excel worksheet).

One consequence of this widespread use is that, now days, naming a class SomeSortOfDto doesn’t tell me much about what the object is for — only that the object carries data, and has no behaviour.

Here’s a few suggestions for better names that might help indicate its purpose:

• SomeSortOfQueryResult
• SomeSortOfQueryParameter
• SomeSortOfCommand
• SomeSortOfConfigItem
• SomeSortOfSpecification
• SomeSortOfRow
• SomeSortOfItem (for a collection)
• SomeSortOfEvent
• SomeSortOfElement
• SomeSortOfMessage

By no means this is a definitive list — it’s just a few examples I can remember using off the top of my head right now. But you get the general idea — try not to call your objects as just DTOs, but give them names that describe their purpose too.

Great new documentation for performance testing

http://blogs.msdn.com/edglas/archive/2010/04/12/great-new-documentation-for-performance-testing-now-online.aspx

Version Control System
A version control system provides versions of not just the software but also of all the documents. Even if a software project consists of just one person, it is always healthy to maintain a version control system. It is good to maintain versions not just for the backup but also because it is easy to revert back changes by selecting any previous version that we want. Popular version control systems are CVS, SVN, VSS. A version control system also provides a method of creating branches, so that we can have development on one branch which we set as the stable version. And we can have a bug fixing branch where we fix bugs. Later once most of the bugs are fixed, we can merge the bug fixes into the stable branch.

Unit Test Framework
Following the concept of test driven development, one part of testing which is under the control of developers is unit testing. Ideally, unit tests should be written along with (or perhaps even before) the implementation. A particular tried and tested unit testing framework such as CUnit can be used. Many of us as developers tend to ignore unit testing and are satisfied by random testing of the system that we create. This is definitely an invitation for letting off unnecessary bugs which will come back far later in the project to haunt us.

Automated Build System
It should be possible to have in addition to manual builds, an automated build system which is triggered by certain events such as nightly builds, change in critical files, etc. An automated build system can help detect a break in the system early. Reports can be generated automatically and sent to the concerned personnel by email. Automated build systems can be created using scripting languages such as perl or python.

Automated Test Framework
One of the most important tools in a software project is the automated test framework. Ideally, the automated tests should be run after every nightly build has successfully completed. As with the build, the test reports if any failure can be generated automatically and sent by email. Automated Test frameworks may be specific to projects.

Task/Defect tracking system
Most useful when the project consists of several members. More so if the members are geographically distributed. A task management system helps to assign tasks, prioritize tasks, set the percentage completed. Charts can be generated to analyse the work done in the project. Microsoft Project is an example of task management or rather project management. A defect tracking system is useful for developers and testers to report bugs, track the progress of fixing those bugs and to analyse the overall defects in the system. Bugzilla, Jira are examples of defect tracking systems.

Wiki/site
Maintain a wiki, website or blog about your project. This can contain the project milestones that are set and achieved. Also information such as project presentations can be added. This can be used not just for team clarity in project achievements but also as a front end for management whenever they need a gist or status of the project.

Interesting article about writing highly available code:
Reliability Features of the .NET Framework

This article discusses:
* Understanding OutOfMemoryException, StackOverflowException, and ThreadAbortException
* Constrained Execution Regions
* Critical Finalizers and SafeHandle
* FailFast and MemoryGates

When using Http, proxy configuration madness is a fact of life. If misconfigured, you can wind up trying to decipher obtuse 502 (Bad Gateway) and 504 (Gateway Timeout) errors.

Fortunately there are a number of binding settings available in WCF to control your Http proxy usage. These settings are available directly on BasicHttpBinding and WsHttpBinding (as well as on HttpTransportBindingElement when you are using a CustomBinding).

* public bool UseDefaultWebProxy (default == true): if set to true, will use the global value HttpWebRequest.DefaultProxy as your proxy. HttpWebRequest.DefaultProxy is controllable through System.Net config, and defaults to using the system proxy settings (i.e. when you see in your Internet Explorer properties).

* public Uri ProxyAddress (default == null): If you want to specify a proxy directly you can set a proxy Uri directly here. To ensure no proxy is used you can specify “null” here. In both cases be sure to set UseDefaultWebProxy = false as well.

* public bool BypassProxyOnLocal (default == false): used in conjunction with ProxyAddress for when you specify a proxy. If you want “local” addresses (i.e. addresses on your intranet) to connect directly without using the proxy, set this value to true.

* public HttpProxyCredentialType HttpTransportSecurity.ProxyCredentialType (default == None): Specifies the authentication mode used with your Http proxy. For custom bindings the equivalent setting is public AuthenticationSchemes ProxyAuthenticationScheme (default == Anonymous) on HttpTransportBindingElement. For proxy authentication we will obtain the credential using the shared WCF provisioning framework (SecurityTokenProvider, etc). We simply pass in the proxy address (rather than the target address) for acquiring these credentials.

One last note about proxies: if you see a 502 or a 504 error returned to your client, then your client is using a proxy server. If this was not your intention, you can disable the server by setting UseDefaultWebProxy to false, and using the default ProxyAddress of null. The other possibility is that your proxy is misconfigured and you can use the above settings to rectify that situation.

Versioning with the Override and New Keywords (C# Programming Guide)

Anyway, I think keyword new for versioning should be avoided as much as possible..
Here is small example:

	public static void RunSnippet()
	{
		Child child = new Child();
		child.Run();
		Intermediate intermediate = new Child();
		intermediate.Run();
		Base bs = new Child();
		bs.Run();
		IClass interf = new Child();
		interf.Run();
		IClass ch2 = new Child2();
		ch2.Run();
	}

	public class Child2 : Intermediate, IClass
	{
		public new void Run()
		{
			WL("Child");
		}
	}

	public class Child : Intermediate
	{
		public new void Run()
		{
			WL("Child");
		}
	}

	public class Intermediate : Base
	{
	}

	public class Base : IClass
	{
		public void Run()
		{
			WL("Base");
		}
	}

	public interface IClass
	{
		void Run();
	}

which produces output:

Child
Base
Base
Base
Child

I want to share this comprehensive blog article by John Robbins. No need to paraphrase the title, it perfectly describes the content already: PDB Files: What Every Developer Must Know.

Sometimes it is helpful to verify a change to isolated storage using the file system of the operating system. Developers might also need to know the location of isolated storage files. This location is different depending on the operating system. The following table shows the root locations where isolated storage is created on a few common operating systems. Look for Microsoft\IsolatedStorage directories under this root location. You must change folder settings to show hidden files and folders in order to see isolated storage in the file system.

In some cases, you may want to access this configuration file programmatically, but the question here is how to know the path of the configuration file without hard coding? After some investigation, I just found a solution to the question, that is using the property: AppDomain.CurrentDomain.SetupInformation.ConfigurationFile, it will return the file path of the configuration file. For example, the following C# code loads the configuration file into a XMLDocument object:

XmlDocument doc = new XmlDocument();
doc.Load(AppDomain.CurrentDomain.SetupInformation.ConfigurationFile);