In today’s software development world; we are solving complex business scenarios and developing large business applications. Hence, proper designing is the major factor which contributes to the scalability and performance of any .NET application.
Efficient Resource Management
Resources are very critical for the existence and survival of any application. Examples of resources include objects, files, connections, handles, streams etc. Hence proper handling and cleanup of such resources is critical for the better performance of system.
Here are points to consider:
- Should properly handle the object creation and cleanup if needed.
- In .NET some objects offer a Close() method to do proper handling of resources. Some of those are db connection, Streams etc.
- .NET provides proper structured blocks which can be used in your code to enforce the cleanup if situation arises. For example, finally blocks or using statements can be used to ensure that resources are closed or released properly and in a timely fashion.
Considerations for Crossings the Application Boundary
Applications live and run in their own territory which is defined by the Machine, Process or Application Domains they are hosted in or deployed on. I.e. if two applications communicate with each other across machine, process r app domain there is significant impact on performance of the application.
- Cross application domain. Since in .NET a process is optimized to have multiple application domains which can then host application inside those app domains. This is the most efficient boundary to cross because it is within the context of a single process.
- Cross process. Crossing a process boundary significantly impacts performance. You should do so only when absolutely necessary. For example, you might determine that an Enterprise Services server application is required for security and fault tolerance reasons.
- Cross machine. Crossing a machine boundary is the most expensive boundary to cross, due to network latency and marshaling overhead. Before introducing a remote server into your design, you need to consider the relative tradeoffs including performance, security, and administration.
Single Large Assemblies or Multiple Smaller Assemblies
In .NET assembly is the unit of deployment; an application comes to an existence in the form of an assembly only. Any application you have built after compilation produces an assembly only. All the .dlls your project refers to are .NET Assemblies only.
When working on designing and architecting a solution it is critical to consider that different functionalities, classes and interfaces etc. should be part of one single chunky assembly or should be divided across multiple smaller assemblies.
Here are points to consider
- To help reduce your application’s working set (in simple terms set of memory pages required to host the application in the process) , you should prefer single larger assemblies rather than multiple smaller assemblies. If you have several assemblies that are always loaded together, you should combine them and create a single assembly.
- Reasons to avoid multiple smaller assemblies:
- Since you have multiple assemblies consider the cost required in loading metadata for multiple smaller assemblies.
- JIT compile time will be much more as per count of assemblies.
- Security checks needed for multiple assemblies.