• Skip to main content
  • Skip to after header navigation
  • Skip to site footer

Shaping Software

Enduring Ideas in the Realm of Software

  • About
  • Topics
  • Best Software Books
  • Archives
  • JD Meier.com

Performance Threats and Countermeasures Framework

Mar 30, 2008 by JD

Performance Threats and Countermeasures Framework

“The goal is to turn data into information, and information into insight.” –Carly Fiorina

On This Page

Performance Hot Spot Categories
Performance Threats
Performance Vulnerabilities
Performance Countermeasures

The Performance Threats and Countermeasures Framework is a comprehensive and organized approach to software performance, utilizing Performance Hot Spots to address common bottlenecks and promote best practices.

During my time working on software performance guidance at Microsoft, I developed a framework I called the Performance Threats and Countermeasures Framework, which proved to be a valuable tool for organizing and prioritizing software performance issues.

I leveraged what I had learned about organizing security knowledge into another framework that I called the Security Threats and Countermeasures framework.  I wanted to create a common way for creating and sharing deeper knowledge within different domains.

I used this Performance Threats and Countermeasures Framework to organize and structure actionable performance knowledge in the form of guidelines and checklists.

I also used it to help build better evaluation criteria to identify key performance decisions that could have a significant impact.

The Performance Threats and Countermeasures Framework allowed everyone to collaborate better and to provide a more comprehensive approach to improving software performance.

Ultimately, the Performance Threats and Countermeasures Framework makes it easier for developers and performance professionals to understand and implement best practices in software performance.

Performance Threats and Countermeasures “Hot Spots” Categories

Over time, I discovered a method to organize our performance principles, patterns, and practices into actionable categories that could group patterns of performance knowledge into themes.

By focusing efforts around related concepts, these themes helped make performance knowledge more actionable.

I referred to these categories as Performance Hot Spots and used them as the backbone for the Performance Threats and Countermeasures Framework. Here are the Performance Hot Spots that I used:

Category Key Considerations
Caching Per user, application-wide, data volatility
Communication Transport mechanism, boundaries, remote interface design, round trips, serialization, bandwidth
Coupling and Cohesion Loose coupling, high cohesion among components and layers
Concurrency Transactions, locks, threading, queuing
Data Access Schema design; Paging; Hierarchies; Indexes; Amount of data; Round trips.
Data Structures / Algorithms Choice of algorithm, Arrays vs. collections
Resource Management Allocating, creating, destroying, pooling
State Management Per user, application-wide, persistence, location

Threats Organized by the Performance Threats and Countermeasures Framework

With the Performance Threats and Countermeasures Framework, it’s easy to walk the categories and think of potential performance problems.

Here’s a list of potential software performance problems, organized by the Performance Threats and Countermeasures framework:

Category 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 / 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.

 

Vulnerabilities Organized by the Performance Threats and Countermeasures Framework

You can also use the Performance Threats and Countermeasures Framework to identify common mistakes that lead to the performance problems above.

Here’s a list of common design mistakes we find in applications that impact software performance:

Category 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

 

Countermeasures Organized by the Performance Threats and Countermeasures Framework

Here’s a list of common design strategies organized by the Performance Threats and Countermeasures Framework that lead to better software performance:

Category 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 / 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 .

Leverage the Performance Threats and Countermeasures Framework to Make Performance More Accessible and Actionable

The Performance Threats and Countermeasures Framework, along with the Performance Hot Spots, have proven to be valuable tools in advancing software performance.

By identifying and categorizing software performance threats and countermeasures, organizations can better prioritize and focus their efforts on the most critical performance issues and build better products, systems, and services.

As technology continues to advance, it is important to continuously optimize and improve software performance, and the Performance Threats and Countermeasures Framework provides a valuable tool for achieving these goals.

Remember, by prioritizing and focusing on key hot spots, you can improve your software’s performance and ultimately provide a better experience for your users.

You Might Also Like

Performance Hot Spots for Organizing Performance Knowledge
Security Threats and Countermeasures Framework
Security Hot Spots for Organizing Security Knowledge

Category: Frames, PerformanceTag: Performance

About JD

Previous Post:STRIDE Explained
Next Post:Context Precision: To Create More Clarity and Relevance, Get More SpecificContext Precision

Reader Interactions

Trackbacks

  1. Security Frame says:
    Apr 7, 2008 at 5:37 am

    […] Performance Frame […]

  2. "Superhero" Post - Response (Plus FeedBurner Mistake We All Made) — Practice This says:
    Apr 26, 2008 at 1:20 pm

    […] Working hard to visit the US this summer and meet you once more. BTW, the “work” is totally based on Performance Frame. […]

  3. Alik Levin's : ASP.NET Performance Engineering - Stress Test Your Architecture, Design, And Code says:
    May 5, 2008 at 10:31 am

    […] Set performance scope using Performance Frame […]

  4. Time Management: Boost Personal Performance With Caching Techniques — Practice This says:
    Jan 9, 2009 at 9:30 pm

    […] To make it effective for the cache one must follow the principles (adapted from performance engineering): […]

  5. Can Conflict Improve Your Personal Performance? — Practice This says:
    Jan 13, 2009 at 6:44 pm

    […] adopted software performance engineering to improve my personal performance. I started to treat conflicts like computers […]

  6. database management software says:
    Nov 3, 2009 at 10:00 am

    database management software…

    What differences and similarities do you see between Asian (India), US and European ideas on database management software?…

Sidebar

Recent Posts

  • What is ChatGPT?
  • Agile Performance Engineering
  • What is Cybersecurity?
  • Software Security Threats: A Comprehensive Guide
  • What is Software Security?

Popular Posts

Best Software Books of All Time
Best Practices for Project Management
Best Practices for Software Development
Customer-Connected Engineering
How To Frame Problems Better
How To Pitch Business Ideas Better
How To Structure Vision Scope Presentations
Intro to Lean Software Development
Lean Principles for Software Development
The Enterprise of the Future