Web Application Performance Frame

Category

Description

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

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

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 and 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

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 / Algorithsm

• 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