This page lists performance heuristics or rule of thumbs for improving the responsiveness and scalability of a software system on the architectural level. Based on the list, some of the heuristics shall be included into the PerOpteryx approach to quicker find good architectural candidates in a metaheuristic search. Also see the related page Reliability Improvements.

List of Heuristics

Reference Name	Type of Improvement	Rule	Reference	How to model in PCM
Bottleneck Mitigation	U (also RT, TP)	Find bottlenecks resources with high utilization and reduce their load.	"Centering" and "Spread-the-load" Principle in Smith2002	Identify processing resources with U>=0.8 and: - allocate components on these nodes to other nodes U<0.2 - increase the processing rate to the next faster resource - replicate the node and its components and introduce load balancer
Long Path Mitigation	RT (also RT, TP)	Find long processing paths and reduce the number of processing steps	"Fast Path" Pattern and Centering Principle in Smith2002	Identifiy the path in the system with the most sequential resource demands and: - reduce the number of network accesses by allocating multiple components onto one node - increase the processing rate of the involved nodes to the next faster resource - introduce a fast path, i.e., an alternative, dedicated component that processes the most frequent requests

Abbreviations

Used above:

RT: Response Time
TP: Throughput
U: Utilization

Notes

Things to consider:

Thread Pools
- requires load dependent servers, not supported
- threading level per component not specified?
- scheduling from Jens not integrated
Asynchronous Communication
- would change the components, not desired
- make a suggestion to the architect to change the components at neuralgic points
Introducing special connector components
- publish/subscribe
- caches, buffers
- Queues
- Busses
Stateless Components
- discuss with Lucia?
Map and Reduce: introduce parallelism
Batching / Caching

Xu2010, Performance Evaluation

Bottleneck Mitigation:
- Multiplicity: add resources to increase its multiplicity
- Redeployment: move some tasks away from a saturated processor
- shift attention to reducing the holding time of a bottlneck resource using long path mitigation
Long Path Mitigation:
- ShrinkExec: reduce the budgeted execution time of operations (<- not applicable for CBSE?)
- MoreAsynch: delay some operations until after replying to the client (<- not applicable for CBSE?)
- Partitioning: repartition the functionality of a saturated task so that more concurrency can be exploited
- Batching: combine operations to reduce requests across a network (<- generate component adapator)
Missing, Future Work:
- Introduction of Caches
- Memory Size Effects
- Selection of Infrastructure components: file systems, database servers, web application servers, communication middleware
- Introduction of Parallelism
- Introduction of Prefetching
- More general version of the batching rule
- Overhead costs for Multithreading
- Throughput capacity requirement
- Performance values other than mean values
- Multiple classes of users

Parsons2009, PhD Thesis

Category1: Antipatterns Across or Within Run-Time Paths
- Transactions-A-Plenty: This rule in figure A.1 identifies a situation where the number of transactions in a particular run-time path are above a user defined threshold value.
- Conversational-Baggage: This rule in figure A.2 identifies a situation where the number of stateful sessions in a particular run-time path are above a user defined threshold value.
- Sessions-A-Plenty: This rule in figure A.3 identifies a situation where the number of stateless sessions in a particular run-time path are above a user defined threshold value or if the ratio of sessions to entities is too high.
Category2: Inter-Component Relationship Antipatterns
- Needless-Session: The rule in figure A.4 identifies a situation where a session bean does not have any relationships with either the database or any entity beans.
- Remote-Calls-Locally: The rule in figure A.5 identifies a situation where two components are running within the same JVM, and one of the components calls the other component through its remote interface
- Accessing-Entities-Directly: The rule in figure A.6 identifies a situation where a web component directly accesses an entity or database component.
- Bloated-Session: The rule in figure A.7 identifies a situation where the number of relationships a session bean has with other beans is above a user specified threshold.
Category3: Antipatterns Related to Component Communication Patterns
- Unusual-or-Bulky-Session-Entity-Communication: The rule in figure A.8 identifies a situation where a frequent sequence exists that has a session as parent and an entity component as its child.
- Fine-Grained-Remote-Calls: The rule in figure A.9 identifies a situation where a frequent sequence exists that has a support level above the user defined threshold (supportAboveTheshold), a rule confidence above the threshold level confidenceAboveThreshold) and which contains two or more remote method calls.
Category4: Data Tracking Antipatterns
- Unused-Data-Object: The rule in figure A.10 identifies a situation where the data in a tracked object is not being accessed more than a user specified percentage level.
Category5: Pooling Antipatterns
- Incorrect-Pool-Size: The rule in figure A.11 identifies a situation where the pool queues have exceeded a user specified threshold.
Category6: Intra-Component Antipatterns
- Local-and-Remote-Simultaneously: The rule in figure A.12 identifies a situation where a component exposes both local and remote interfaces.

.NET Performance Guide

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 restrictions.
- 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 supports 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.
- Restrict use of late binding and only use late binding where it is necessary and appropriate.

Communication
- Interfaces 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 communication 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.
- Do not use processes where application domains are more appropriate.

Concurrency
- In your application do not create threads on a per-request basis, and use the common language runtime (CLR) thread pool instead.
- Only types that need to be thread-safe are made thread-safe.
- Carefully consider lock granularity..
- Ensure your application acquires shared resources and locks late and releases them early to reduce contention.
- Choose appropriate synchronization primitives.
- 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 procedure 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 on scalability if you decided to use stateful components.
- If you use Microsoft® .NET Framework remoting and need to support load balancing, you use single call server-activated objects (SAO).
- If you use Web services, you also use a message-based stateless programming model.
- If you use Enterprise Services, also use stateless components to facilitate object pooling.
- Objects that you want to store in state stores support serialization.
- Consider the performance impact of view state.
- Use statistics relating to the number of concurrent sessions and average session data per user to help choose an appropriate session state store.

Data Structures and Algorithms
- Ensure your design uses appropriate data structures.
- Use custom collections only where absolutely necessary.
- Extend the IEnumerable interface for your custom collections.

Data Access
- Pass data across the layers by using the most appropriate data format. Carefully consider the performance implications.
- Use stored procedures with the Parameters collection for data access.
- Only process the data that is required.
- Where appropriate, provide data paging solutions for large result sets.
- Use Enterprise Services declarative transactions for transactions that span multiple resource managers or where you need to flow transaction context across components.
- If you manipulate binary large objects (BLOBs), use appropriate chunking techniques, and do not repeatedly move the same BLOB.
- Consolidate repeated data access code into helper classes.

Exception Handling
- Do not use exceptions to control regular application flow.
- Use well-defined exception handling boundaries.
- 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.

Design Considerations
- Classes own the data that they act upon.
- Do not use explicit interfaces unnecessarily. Use explicit interfaces for versioning and for polymorphism where you have common functionality across multiple classes.
- Classes do not contain virtual methods when they are not needed.
- Prefer overloaded methods to methods that take variable parameters.

Rozanski/Woods2005

Architekturtaktiken für Performance und Skalierbarkeit:

Minimiere Nutzung gemeinsamer Ressourcen
Konsolidiere Berechnungen (Batch Processing)
Finde und entferne Flaschenhälse (Bottlenecks)
Partitioniere und parallelisiere Berechnungen
Nutze asynchrone Berechnungen
Priorisiere Berechnungen
Optimiere wiederholte Berechnungen (Profiling)