Performance Architecture Checklist

This checklist can be used to help you in your design for a scalable application. The idea is, you take performance into consideration while you are designing your architecture, not after done.


You will need to think carefully, which matters apply to you and how you will have to implement them.
This is not a silver bullet, but a mental exercise.

Deployment and Infrastructure

• Use distributed architectures appropriately. Do not introduce distribution unnecessarily! 
• Carefully select appropriate distributed communication mechanisms. 
• Locate components that interact frequently within the same boundary or as close to each other as possible. 
• Take infrastructure restrictions into account in your design 
• Consider network bandwidth restriction 
• Identify resource restrictions. 
• Ensure your design does not prevent you from scaling up. 
• Ensure your design does not prevent you from scaling out and it uses logical layers, does not unwittingly introduce affinity, and support load balancing!

Coupling and Cohesion

• Ensure your design is loosely coupled.
• Exhibit appropriate degrees of cohesion in your design and group together logically related entities, such as classes and methods.

Communication

• Interface do not enforce chatty communication.
• Ensure your application only makes remote calls where necessary. Impact is minimized by client-side validation, client-side caching, and batching of work.
• Optimize remote data exchange.
• Choose appropriate secure communications mechanisms.
• Use message queues to decouple component parts of your system.
• Mitigate the impact of long-running calls by using message queues, “fire-and-forget” approaches, and asynchronous method calls.

Concurrency

• Watch out which types you use. Many basic types have locking behaviour. Example HashMap, instead when in doubt, use Concurrent(HashMap).
• Carefully consider lock granularity. Synchronised(writes > reads) or locks (reads > writes).
• Ensure your application acquires shared resources and locks late and releases them early to reduce contention.
• Choose an appropriate transaction isolation level.
• Ensure your application uses asynchronous execution for I/O bound tasks and not for CPU bound tasks.

Resource Management

• Ensure your design supports and makes effective use of pooling.
• Ensure your application acquires resources late and releases them early.

Caching

• Use caching for data that is expensive to retrieve, compute, and render.
• Cache appropriate data such as relatively static Web pages, specific items of output data, stored procedures parameters, and query results.
• Do not use caching for data that is too volatile.
• Select an appropriate cache location.
• Select an appropriate cache expiration policy.

State management

• Your design favors stateless components. Or, you considered the negative impact of scalability if you decided to use stateful components.
• If you use Web services, you also use a message-based stateless programming model.
• Make objects you want to store serializable.
• Consider performance impact of what you put in your session.
• Use statistics to help you, get your thread pool and sessions duration wright.

Data structures and Algorithms

• Ensure your design uses appropriate data structures.
• Use custom collections only where absolutely necessary.

Data Access

• Pass data across the layers by using the most appropriate data format. Carefully consider the performance implications.
• Use stored procedures for complex data access.
• As rule: Don’t use loops, when accessing data with your ORM(example hibernate).
• Only process the data that is required. (Less is more)
• Where appropriate, provide data paging solution for large result sets.

Exception Handling

• Do not use exceptions to control regular application flow.
• example: if you control a Single Sign On system, when the user mistypes his password. This is a normal flow!
• Structured exception handling is the preferred error handling mechanism. Do not rely on error codes.
• Only catch exceptions for a specific reason and when it is required.

Monitoring

• Implement monitoring in your application, that can be turned on and off. When turned of this should have zero impact.
• Implement Application Monitoring. Showing you where time is being spend in your application
• Implement User Performance Monitoring. This will let your see where the user is spending his time.
• Allow tracing over multiple tiers.
• Automatically monitor slow request.
• Implement sampling of your data. This will lower the impact when you need to monitor your application.
• Use the statistics for your monitoring, when you are thinking of making adjustments to your architecture.

Common Sense

Use it!

This checklist originated/(largely based) from the Microsoft best practices. Please continue reading there. It’s a very good site with lots of help full tips, while being only slightly outdated. This show that performance is not technology specific.