Telephone: (215) 716-7373


Home » Application & NetAnalysis » Baselining--Stress Testing--Performance Testing--Oh My--Part ONE


Baselining--Stress Testing--Performance Testing--Oh My--Part ONE

Bookmark and Share

Click Here to Listen to this topic as a "The ROOT Cause" podcast.  

 

Click Here to Subscribe through

 

Click Here to Subscribe through  


This is the first article of a series of two. "Baselining--Stress Testing--Performance Testing--Oh My--Part One--Environments," lays out where you test--not the details of how

The second article is, "Baselining--Stress Testing--Performance Testing--Oh My--Part Two--Testing."  It drills down in the goals and processes of the various types of testing strategies--not where they are done.

What testing environments does your organization maintain?  DEV, QA, UAT, Parallel Production?  There is great variation in the way different organizations use and design these environments.  Some are more useful than others.

TESTING ENVIRONMENTS

DEV:  This is just for developers and very seldom sees Application Profiling or Stress Testing.  But, why not?  Wouldn't it benefit developers to see how their code works across a network?   It can be a single PC under someone's desk--running services and applications representing all the Tiers of the Production environment, or it can be quite robust.

QA:  This is not really the best environment for clients, end-users or business users to do Acceptance Testing.  Nevertheless, it is very common for it be used that way.  This is where code that has been tested in DEV goes to be tested by other teams--vigorously.  It most certainly should be Stress Tested and fully analyzed by Application Profiling at this point. 

While there may be different levels of QA, this environment is often too small.  In order to be most useful in its role of anticipating the applications performance in PROD, it needs to be large enough to simulate such an environment.  Consider making it a SCALED down version of PROD.  I mean that literally.  If it were a copy of PROD, more or less to scale--its performance would be much more transferable to a PROD reality.  It is unlikely to be the same size--but can it be one quarter the size?  How about one tenth?  The size is less important than having a consistent ratio--keeping it to scale so that metrics are convertible.

Another Best Practice in the QA environment is to use production data wherever possible.  Since no clients ever use it (see UAT), and it mirrors the security offered by PROD (I hope), this may be done safely.  Then the Databases have the same characteristics--keeping the outcome closer to reality.    

UAT (User Acceptance Testing):  Where clients, end users and business users can go to test functionality and acceptability of the code.   Unfortunately, this role is too often seen performed in the QA environment.   However, with a dedicated UAT Environment, you can present clean information in an environment that is not subject to the same "slings and arrows" that are thrown at QA.  Here the Client can do what they want.  The goal for them here is to test functionality, not load.  However, if they want to test load, they can do so.  Therefore, it is best to build this environment to scale as well.  Nevertheless, the ratios can be such that the UAT environment is smaller than QA.  What matters most is that it function as close to PROD as possible.

PARALLEL PRODUCTION:  This is a very valuable subset environment of UAT.  Here we set up a "ready for prime time" version.  It runs on PROD hardware in PROD networks, but in UAT volumes or other forms of segregation.  The goal is to see how close to reality you can get using as much production equipment and environment as possible--without breaking PROD.  It's not as difficult or dangerous as it sounds when planned out well and can save MILLIONS of DOLLARS in lost time and productivity--not to mention careers.

Here is how this works.  You have volumes and directories on your non-prod servers.  Create new and comparable volumes and directories on the same PROD servers that you plan on using for the application and put the data there.  It is now running on a the PROD box--but not completely in the PROD environment. 

Yes--there are issues with DNS and other such things, but they can be worked out for a set of Test Users.  Remember, this is going LIVE very soon.  Don't you want to find out what will happen with a way to rollback easily?  This is NOT an alternative to UAT or QA.  It happens after the application has passed all of those tests.  It is an alternative to going straight into PROD.  If you have sufficient doubts about the application or configuration, so that a Parallel Production test seems scary--you shouldn't be planning on going live yet.  This is an additional step--it does not replace anything.  Well, it does replace going straight from UAT to PROD--but that is a good thing.

 




Related Topics:


Back to main topic: Application & NetAnalysis
The Application's Interpath
Network & Application Performance Analysis Fundamentals
Building a Simple Open-Source Distributed Packet-Sniffer
Performance Tuning Is A Process -- Not A Tool
Excessive TCP Connections
Why Network Assessments Must Include Application Behavior
The 7 Most Common Mistakes Using Packet-Sniffers
Packet-Sniffer Filtering Concepts-01
Interpath Application Flow Diagrams-01
Baselining--Stress Testing--Performance Testing--Oh My--Part TWO
The Saturation Point
Multi-Tier Latency Concepts-01
Application Profiling Concepts - Part One

Subscribe to receive the latest news & specials on our products:

Quick Find
 
Use keywords to find the product you are looking for.
Advanced Search

Articles
New Articles
All Topics
 
 Application & NetAnalysis
 Case Studies .
 NetAnalysis Myth Series
 Podcasts
 Team Building
Articles RSS Feed
Information
Shipping & Returns
Privacy Notice
Conditions of Use
Newsletter
Contact Us
Catalog Feed

Copyright © 1999-2013 Barry Koplowitz