Performance Frame - v2
The Performance Frame helps you organize and prioritize performance knowledge.
| Category | Key Considerations |
|---|---|
| Caching | Per user, application-wide, data volatility. |
| Communication | Transport mechanism, boundaries, remote interface design, round trips, serialization, bandwidth. |
| Concurrency | Transactions, locks, threading, queuing. |
| Coupling / Cohesion | Loose coupling, high cohesion among components and layers. |
| Data Access | Schema design; Paging; Hierarchies; Indexes; Amount of data; Round trips. |
| Data Structures / Algorithms | Choice of algorithm; Arrays vs. collections. |
| Exception Management | Where to validate; Whether to throw; Whether to catch. |
| Resource Management | Allocating, creating, destroying, pooling. |
| State Management | Per user, application-wide, persistence, location. |
Vulnerabilities
| Category | Key Considerations |
|---|---|
| Caching | Not using caching when you can; Updating your cache more frequently than you need to; Caching the inappropriate form of data; Caching volatile or user - specific data; Holding cache data for prolonged periods; Not having a cache synchronization mechanism in Web farm |
| Communication | Chatty interfaces; Sending more data than you need; Ignoring boundary costs. |
| Concurrency | Blocking calls; Nongranular locks; Misusing threads; Holding onto locks longer than necessary; Inappropriate isolation levels. |
| Coupling / Cohesion | Not using logical layers; Object-based communication across boundaries |
| Data Access | Poor schema design; Failure to page large result sets; Exposing inefficient object hierarchies when simpler would do; Inefficient queries or fetching all the data; Poor indexes or stale index statistics; Failure to evaluate the processing cost on your database server and your application. |
| Data Structures / Algorithms | Choosing a collection without evaluating your needs (size, adding, deleting, updating); Using the wrong collection for a given task; Excessive type conversion; Inefficient lookups; Not measuring the cost of your data structures or algorithms in your actual scenarios. |
| Exception Management | Poor client code validations; Exceptions as a method of controlling regular application flow; Throwing and catching too many exceptions; Catching exceptions unnecessarily. |
| Resource Management | Not pooling costly resources; Holding onto shared resources; Accessing or updating large amounts of data; Not cleaning up properly; Failing to consider how to throttle resources. |
| State Management | Stateful components; Use of an in-memory state store; Storing state in the database or server when the client is a better choice; Storing state on the server when a database is a better choice; Storing more state than you need; Prolonged sessions . |
Threats
| Category | Key Considerations |
|---|---|
| Caching | Round trips to data store for every single user request, increased load on the data store; Increased client response time, reduced throughput, and increased server resource utilization. Increased memory consumption, resulting in reduced performance, cache misses, and increased data store access; Frequently changing data requires frequent expiration of cache, resulting in excess usage of CPU, memory, and network resources; With inappropriate expiration policies or scavenging mechanisms, your application serves stale data; This means that the cache in the servers in the farm is not the same and can lead to improper functional behavior of the application. |
| Communication | Requires multiple round trips to perform a single operation; By sending more data than is required, you increase serialization overhead and network latency; Boundary costs include security checks, thread switches, and serialization. |
| Concurrency | Stalls the application, and reduces response time and throughput; Stalls the application, and leads to queued requests and timeouts; Additional processor and memory overhead due to context switching and thread management overhead; Causes increased contention and reduced concurrency; Poor choice of isolation levels results in contention, long wait time, timeouts, and deadlocks. |
| Coupling / Cohesion | Mixing functionally different logic (such as presentation and business) without clear, logical partitioning limits scalability options; Chatty interfaces lead to multiple round trips. |
| Data Access | Increased database server processing; reduced throughput; Increased network bandwidth consumption; delayed response times; increased client and server load; Increased garbage collection overhead; increased processing effort required; Inefficient queries or fetching all the data to display a portion is an unnecessary cost, in terms of server resources and performance; Creates unnecessary load on the database server; Failure to meet performance objectives and exceeding budget allocations. |
| Data Structures / Algorithms | Reduced efficiency; overly complex code; Reduced efficiency; overly complex code; Passing value type to reference type causing boxing and unboxingCaching Decide overhead, causing performance hit; Complete scan of all the content in the data structure, resulting in slow performance; Undetected bottlenecks due to inefficient code. |
| Exception Management | Round trips to servers and expensive calls; Expensive compared to returning enumeration or Boolean values; Increased inefficiency; Adds to performance overhead and can conceal information unnecessarily. |
| Resource Management | Can result in creating many instances of the resources along with its connection overhead; Increase in overhead cost affects the response time of the application; Not releasing (or delaying the release of) shared resources, such as connections, leads to resource drain on the server and limits scalability; Retrieving large amounts of data from the resource increases the time taken to service the request, as well as network latency; This should be avoided, especially on low bandwidth access, because it affects response time; Increase in time spent on the server also affects response time as concurrent users increase; Leads to resource shortages and increased memory consumption; both of these affect scalability; Large numbers of clients can cause resource starvation and overload the server. |
| State Management | Holds server resources and can cause server affinity, which reduces scalability options. Limits scalability due to server affinity; Increased server resource utilization; limited server scalability; In-process and local state stored on the Web server limits the ability of the Web application to run in a Web farm. Large amounts of state maintained in memory also create memory pressure on the server; Increased server resource utilization, and increased time for state storage and retrieval; Inappropriate timeout values result in sessions consuming and holding server resources for longer than necessary. |
Countermeasures
| Category | Key Considerations |
|---|---|
| Caching | Decide where to cache data; Decide what data to cache; Decide the expiration policy and scavenging mechanism; Decide how to load the cache data; Avoid distributed coherent caches. |
| Communication | Choose the appropriate remote communication mechanism; Design chunky interfaces; Consider how to pass data between layers; Minimize the amount of data sent across the wire; Batch work to reduce calls over the network; Reduce transitions across boundaries; Consider asynchronous communication; Consider message queuing; Consider a "fire and forget" invocation model. |
| Concurrency | Reduce contention by minimizing lock times; Balance between coarse- and fine-grained locks; Choose an appropriate transaction isolation level; Avoid long-running atomic transactions. |
| Coupling / Cohesion | Design for loose coupling; Design for high cohesion; Partition application functionality into logical layers; Use early binding where possible; Evaluate resource affinity. |
| Data Access | Consider abstraction versus performance; Consider resource throttling; Consider the identities you flow to the database; Separate read-only and transactional requests; Avoid unnecessary data returns. |
| Data Structures / Algorithms | Choose an appropriate data structure; Pre-assign size for large dynamic growth data types; Use value and reference types appropriately. |
| Exception Management | 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. |
| Resource Management | Treat threads as a shared resource; Pool shared or scarce resources; Acquire late, release early; Consider efficient object creation and destruction; Consider resource throttling. |
| State Management | Evaluate stateful versus stateless design; Consider your state store options; Minimize session data; Free session resources as soon as possible; Avoid accessing session variables from business logic. |
The categories in the frame are a prioritized set of technology-agnostic common denominators that are pervasive across applications. You can use the categories to build evaluation criteria where performance decisions can have a large impact.
My Related Posts