IT training effective application performance testing hpe khotailieu

1 Making sure your application is ready to test 3Allocating enough time to performance test 5Obtaining a code freeze 6Designing and provisioning a performance test environment 7Setting r

Ian Molyneaux

The Fundamentals

Effective Application Performance Testing

Compliments of

Thrive in the new now:

Engineering for the Digital age

Is your application fast enough?

Get your custom HPE Insights performance report NOW to learn how your application is

performing: www.hpe.com/software/insights

You will receive a detailed performance report in less than 5 minutes

Hewlett Packard Enterprise software enables you to deliver amazing applications with speed, quality and scale Learn more:

Mobile testing Web Performance & Network Simulate constrained

This report is an excerpt containing Chapter 3 of

the book The Art of Application Performance Testing, Second Edition The complete book is

available at oreilly.com and through other

retailers.

Ian Molyneaux

Effective Application Performance Testing

The Fundamentals

[LSI]

Effective Application Performance Testing

by Ian Molyneaux

Copyright © 2017 O’Reilly Media, Inc All rights reserved.

Printed in the United States of America.

Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.

O’Reilly books may be purchased for educational, business, or sales promotional use Online editions are also available for most titles (http://safaribooksonline.com) For more information, contact our corporate/institutional sales department:

800-998-9938 or corporate@oreilly.com.

Editors: Brian Anderson and Virginia

Wilson

Production Editor: Shiny Kalapurrakel

Copyeditor: Rachel Monaghan

Proofreader: Sharon Wilkey

Interior Designer: David Futato

Cover Designer: Ellie Volkhausen

Illustrator: Rebecca Demarest February 2017: First Edition

Revision History for the First Edition

2017-02-26: First Release

The O’Reilly logo is a registered trademark of O’Reilly Media, Inc Effective Applica‐ tion Performance Testing, the cover image, and related trade dress are trademarks of

O’Reilly Media, Inc.

While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author disclaim all responsibility for errors or omissions, including without limi‐ tation responsibility for damages resulting from the use of or reliance on this work Use of the information and instructions contained in this work is at your own risk If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsi‐ bility to ensure that your use thereof complies with such licenses and/or rights.

Table of Contents

The Fundamentals of Effective Application Performance Testing 1

Making sure your application is ready to test 3Allocating enough time to performance test 5Obtaining a code freeze 6Designing and provisioning a performance test

environment 7Setting realistic performance targets 18Identifying and scripting the business-critical use cases 28Provisioning test data 32Ensuring accurate performance test design 36

In summary 44

The Fundamentals of Effective Application Performance Testing

For the want of a nail

—Anonymous

This chapter focuses on what is required to performance test effec‐tively, that is the non-functional requirements (NFR’s) or prerequi‐sites The idea of a formal approach to performance testing is stillconsidered novel by many, although the reason is something of amystery, because (as with any kind of project) failing to plan prop‐erly will inevitably lead to misunderstandings and problems

Performance testing is no exception If you don’t plan your softwaredevelopment projects with performance testing in mind, then youexpose yourself to a significant risk that your application will neverperform to expectation As a starting point with any new softwaredevelopment project, you should ask the following questions:

• How many end users will the application need to support atrelease? After 6 months, 12 months, 2 years?

• Where will these users be located, and how will they connect tothe application?

• How many of these users will be concurrent at release? After 6months, 12 months, 2 years?

These answers then lead to other questions, such as the following:

• How many and what specification of servers will I need for eachapplication tier?

• Where should these servers be hosted?

• What sort of network infrastructure do I need to provide?You may not be able to answer all of these questions definitively orimmediately, but the point is that you’ve started the ball rolling bythinking early on about two vital topics, capacity and the end userexperience, which (should) form an integral part of the design pro‐cess and its impact on application performance and availability

You have probably heard the terms functional and non-functional

requirements Broadly, functional requirements define what a sys‐tem is supposed to do, and nonfunctional requirements (NFRs)define how a system is supposed to be (at least according to Wikipe‐dia)

In software testing terms, performance testing is a measure of the

performance and capacity quality of a system against a set of bench‐

mark criteria (i.e., what the system is “supposed to be”), and as suchsits in the nonfunctional camp Therefore, in my experience, to per‐formance test effectively, the most important considerations includethe following:

• Project planning

— Making sure your application is stable enough for perfor‐mance testing

— Allocating enough time to performance test effectively

— Obtaining a code freeze

• Essential NFRs

— Designing an appropriate performance test environment

— Setting realistic and appropriate performance targets

— Identifying and scripting the business-critical use cases

— Providing test data

— Ensuring accurate performance test design

— Identifying the Infrastructure KPIs to monitor

— Creating an accurate Load Model

There are a number of possible mechanisms for gath‐

ering requirements, both functional and nonfunc‐

tional For many companies, this step requires nothing

more sophisticated than Microsoft Word But serious

requirements management, like serious performance

testing, benefits enormously from automation A num‐

ber of vendors provide tools that allow you to manage

requirements in an automated fashion; these scale

from simple capture and organization to solutions with

full-blown Unified Modeling Language (UML) compli‐

Making sure your application is ready to test

Before considering any sort of performance testing, you need toensure that your application is functionally stable This may seemlike stating the obvious, but all too often performance testingmorphs into a frustrating bug-fixing exercise, with the time alloca‐ted to the project dwindling rapidly Stability is confidence that anapplication does what it says on the box If you want to create a pur‐chase order, this promise should be successful every time, not 8times out of 10 If there are significant problems with applicationfunctionality, then there is little point in proceeding with perfor‐mance testing because these problems will likely mask any that arethe result of load and stress It goes almost without saying that codequality is paramount to good performance You need to have aneffective unit and functional test strategy in place

I can recall being part of a project to test the performance of aninsurance application for a customer in Dublin, Ireland The cus‐tomer was adamant that the application had passed unit/regressiontesting with flying colors and was ready to performance test Aquick check of the database revealed a stored procedure with an exe‐cution time approaching 60 minutes for a single iteration! This is anextreme example, but it serves to illustrate my point There are toolsavailable that help you to assess the suitability of your application toproceed with performance testing The following are some commonareas that may hide problems:

High data presentation

Your application may be functionally stable but have a high net‐work data presentation due to coding or design inefficiencies Ifyour application’s intended users have limited bandwidth, thensuch behavior will have a negative impact on performance, par‐ticularly over the last mile Excessive data may be due to largeimage files within a web page or large numbers of redundantconversations between client and server

Poorly performing SQL

If your application makes use of an SQL database, then theremay be SQL calls or database stored procedures that are badlycoded or configured These need to be identified and correctedbefore you proceed with performance testing; otherwise, theirnegative effect on performance will only be magnified byincreasing load (see Figure 1-1)

Large numbers of application network round-trips

Another manifestation of poor application design (or protocolbehaviour) is large numbers of conversations leading to exces‐sive network chattiness between application tiers High num‐bers of conversations make an application vulnerable to theeffects of latency, bandwidth restriction, and network conges‐tion The result is performance problems in this sort of networkcondition

Undetected application errors

Although the application may be working successfully from afunctional perspective, there may be errors occurring that arenot apparent to the users (or developers) These errors may becreating inefficiencies that affect scalability and performance

An example is an HTTP 404 error in response to a nonexistent

or missing web page element Several of these in a single trans‐action may not be a problem, but when multiplied by severalthousand transactions per minute, the impact on performancecould be significant

Figure 1-1 Example of (dramatically) bad SQL performance

Allocating enough time to performance test

It is extremely important to factor into your project plan enoughtime to performance test effectively This cannot be a “finger in theair” decision and must take into account the following considera‐tions:

Lead time to prepare test environment

If you already have a dedicated performance test environment,

this requirement may be minimal Alternatively, you may have

to build the environment from scratch, with the associated timeand costs These include sourcing and configuring the relevanthardware as well as installing and configuring the applicationinto this environment

Lead time to provision sufficient load injectors

In addition to the test environment itself, consider also the timeyou’ll need to prepare the resource required to inject the load.This typically involves a workstation or server to manage theperformance testing and multiple workstations/servers to pro‐vide the load injection capability

Time to identify and script use cases

It is vitally important to identify and script the use cases thatwill form the basis of your performance testing Identifying theuse cases may take from days to weeks and be challenging toestimate accurately As a suggestion I tend to estimate scriptingeffort as 0.5 days per use case, assuming an experienced techni‐cian The performance test scenarios are also normally con‐structed and validated as part of this process By way ofexplanation, a use case is a discrete piece of application func‐tionality that is considered high volume or high impact It can

be as simple as navigating to a web application home page or ascomplex as completing an online mortgage application

Time to identify and create enough test data

Because test data is key to a successful performance testingproject, you must allow enough time to prepare it This is often

a nontrivial task and may take many days or even weeks Youshould also consider how long it may take to reset the targetdata repository or re-create test data between test executions, ifnecessary

Time to instrument the test environment

This covers the time to install and configure any monitoring ofthe application landscape to observe the behavior of the applica‐tion, servers, database, and network under load This mayrequire a review of your current tooling investment and discus‐sions with Ops to ensure that you have the performance visibil‐ity required

Time to deal with any problems identified

This can be a significant challenge, since you are dealing withunknowns However, if sufficient attention has been given toperformance during development of the application, the risk ofsignificant performance problems during the testing phase issubstantially reduced That said, you still need to allocate timefor resolving any issues that may crop up This may involve theapplication developers and code changes, including liaison withthird-party suppliers

Obtaining a code freeze

There’s little point in performance testing a moving target It is abso‐lutely vital to carry out performance testing against a consistentrelease of code If you find problems during performance testingthat require a code change, that’s fine, but make sure the developersaren’t moving the goalposts between or, even worse, during testcycles without good reason

If they do, make sure somebody tells the testing team! As mentionedpreviously, automated performance testing relies on scripted usecases that are a recording of real user activity These scripts are nor‐mally version dependent; that is, they represent a series of requests

and expected responses based on the state of the application at the

time they were created.

An unanticipated new release of code may partially or completelyinvalidate these scripts, requiring in the worst case that they be com‐pletely re-created More subtle effects may be an apparently success‐ful execution but an invalid set of performance test results, becausecode changes have rendered the scripts no longer an accurate repre‐sentation of end-user activity This is a common problem that oftenhighlights weaknesses in the control of building and deploying soft‐ware releases and the communication between the Dev and QAteams.

Designing and provisioning a performance test environment

Next we need to consider the performance test environment In anideal world, it would be an exact copy of the production environ‐ment, but for a variety of reasons this is rarely the case

The number and specification of servers (probably the most common reason)

It is often impractical, for reasons of cost and complexity, toprovide an exact replica of the server content and architecture

in the test environment Nonetheless, even if you cannot repli‐cate the numbers of servers at each application tier, try to atleast match the specification of the production servers This willallow you to determine the capacity of an individual server andprovide a baseline for modeling and extrapolation purposes

Bandwidth and connectivity of network infrastructure

In a similar vein, it is uncommon for the test servers to bedeployed in the same location as their production counterparts,although it is often possible for them to share the same networkinfrastructure

Tier deployment

It is highly desirable to retain the production tier deploymentmodel in your performance test environment unless there isabsolutely no alternative For example, if your productiondeployment includes a web,application and database tier, thenmake sure this arrangement is maintained in your performancetest environment even if the number of servers at each tier can‐not be replicated Avoid the temptation to deploy multipleapplication tiers to a single physical or virtual platform

Sizing of application databases

The size and content of the test environment database shouldclosely approximate the production one; otherwise, the differ‐ence will have a considerable impact on the validity of perfor‐mance test results Executing tests against a 1 GB database whenthe production deployment will be 1 TB is completely unrealis‐tic

Therefore, the typical performance test environment is a subset ofthe production environment Satisfactory performance here suggeststhat things can only get better as we move to full-blown deployment.(Unfortunately, that’s not always true!)

I have come across projects where all performance testing was car‐ried out on the production environment However, this is still fairlyunusual and adds its own set of additional considerations, such asthe effect of other application traffic and the impact on real applica‐tion users when a volume performance test is executed Such testing

is usually scheduled out of normal working hours in order to mini‐mize external effects on the test results and the impact of the testing

on the production environment

In short, you should strive to make the performance test environ‐ment as close a replica of production as possible within existing con‐straints This requirement differs from functional testing, where theemphasis is on ensuring that the application works correctly Themisconception persists that a minimalist deployment will be suitablefor both functional and performance testing (Fail!) Performance

testing needs a dedicated environment Just to reiterate the point:

unless there is absolutely no way to avoid it, you should not use the same environment for functional and performance testing.

For example, one important UK bank has a test lab set up to repli‐cate its largest single branch This environment comprises over 150workstations, each configured to represent a single teller, with all thesoftware that would be part of a standard desktop build On top ofthis is deployed test automation software providing an accurate sim‐ulation environment for functional and performance testingprojects

As you can see, setting up a performance test environment is rarely

a trivial task and you need to allow for a realistic amount of time tocomplete this activity

To summarize, there are three levels of preference when it comes todesigning a performance test environment:

An exact or very close copy of the production environment

This ideal is often difficult to achieve for practical and commer‐cial reasons

A subset of the production environment with fewer servers but specifi‐ cation and tier-deployment matches to that of the production environ‐ ment

This is frequently achievable—the important considerationbeing that from a bare-metal perspective, the specification ofthe servers at each tier should match that of the productionenvironment This allows you to accurately assess the capacitylimits of individual servers, providing you with a model toextrapolate horizontal and vertical scaling

A subset of the production environment with fewer servers of lower specification

This is probably the most common situation; the performancetest environment is sufficient to deploy the application, but thenumber, tier deployment, and specification of servers may differsignificantly from the production environment and should not

be used for capacity testing

Virtualization

A common factor influencing test environment design is the use ofvirtualization technology that allows multiple virtual server instan‐ces to exist on a single physical machine VMWare remains the mar‐ket leader despite challenges from other vendors (such as Microsoft)and open source offerings from Xen

On a positive note, virtualization makes a closer simulation possiblewith regard to the number and specification of servers present in theproduction environment It also simplifies the process of addingmore RAM and CPU power to a given server deployment If theproduction environment also makes use of virtualization, then somuch the better, since a very close approximation will then be possi‐ble between test and production

Possible negatives include the fact that you generally need more vir‐tual than physical resources to represent a given bare-metal specifi‐cation, particularly with regard to CPU performance where virtual

servers deal more in virtual processing units rather than CPU cores.The following are some other things to bear in mind when compar‐ing logical (virtual) to physical (real) servers:

Hypervisor layer

Any virtualization technology requires a management layer

This is typically provided by what is termed the hypervisor,

which acts as the interface between the physical and virtualworld The hypervisor allows you to manage and deploy yourvirtual machine instances but invariably introduces an overheadinto the environment You need to understand how this willimpact your application behavior when performance testing

Bus versus LAN-WAN

Communication between virtual servers sharing the same phys‐ical bus will exhibit different characteristics than servers com‐municating over LAN or WAN Although such virtual

communication may use virtual network interface cards (NICs),

it will not suffer (unless artificially introduced) typical networkproblems like bandwidth restriction and latency effects In adata center environment there should be few network problems,

so this should not be an issue

However, if your physical production servers connect across dis‐tance via LAN or WAN, then substituting common-bus virtualservers in test will not give you a true representation of server-to-server communication In a similar vein, it is best (unless you arematching the production architecture) to avoid deploying virtualservers from different tiers on the same physical machine In otherwords, don’t mix and match: keep all web, application, and databasevirtual servers together but on different physical servers

Physical versus virtual NICs

Virtual servers tend to use virtual NICs This means that, unlessthere is one physical NIC for each virtual server, multipleservers will have to share the same physical NIC Current NICtechnology is pretty robust, so it takes a lot to overload a card.However, channeling several servers’ worth of network trafficdown a single NIC increases the possibility of overload I wouldadvise minimizing the ratio of physical NICs to virtual servers

Cloud computing

The emergence of cloud computing has provided another avenuefor designing performance test environments You could argue thatthe cloud, at the end of the day, is nothing more than commoditizedvirtualized hosting; however, the low cost and relative ease of envi‐ronment spin-up and teardown makes the cloud an attractive optionfor hosting many kinds of test environments

Having gone from novelty to norm in a few short years, cloud com‐puting has become one of the most disruptive influences on IT sincethe appearance of the Internet and the World Wide Web Amazonhas made the public cloud available to just about anyone who wants

to set up her own website, and now other cloud vendors, too numer‐ous to mention, offer public and private cloud services in all kinds ofconfigurations and cost models

The initial concerns about data security have largely been dealt with,and the relatively low cost (provided you do your homework) andalmost infinite horizontal and vertical flex (server spin-up/spin-down on demand) make the cloud a very compelling choice forapplication hosting, at least for your web tier If you don’t want theworry of managing individual servers, you can even go down thePlatform as a Service (PaaS) route, principally offered by MicrosoftAzure and Amazon AWS with their Elastic Beanstalk offering

So is cloud computing a mini-revolution in IT? Most definitely, buthow has the adoption of the cloud affected performance testing?

Load injection heaven

One of the biggest historical bug-bears for performance testinghas been the need to supply large amounts of hardware to injectload For smaller tests ,say up to a couple of thousand virtualusers, this may not have been too much of a problem, but whenyou started looking at 10,000, 20,000, or 100,000 virtual users,the amount of hardware typically required often becameimpractical, particularly where the application tech stackimposed additional limits on the number of virtual users youcould generate from a given physical platform

Certainly, hardware costs have come down dramatically over the last

10 years and you now get considerably more bang for your buck interms of server performance; however, having to source, say, 30servers of a given spec at short notice for an urgent performance

testing requirement is still unlikely to be a trivial investment in timeand money Of course, you should be managing performance testingrequirements from a strategic perspective, so you should never be inthis situation in the first place That said, the cloud may give you ashort-term way out while you work on that tactical, last-minute per‐formance mind-set.

On the surface, the cloud appears to solve the problem of load injec‐tor provisioning in a number of ways, but before embracing loadinjection heaven too closely, you need to consider a few importantthings

On the plus side:

It’s cheap.

Certainly, the cost per cloud server even of comparatively highspec borders on the trivial, especially given that you need theservers to be active only while the performance test is executing

A hundred dollars can buy you a lot of computing power

It’s rapid (or relatively so).

With a little planning you can spin up (and spin down) a verylarge number of injector instances in a comparatively short

time I say comparatively in that 1,000 injectors might take 30+

minutes to spin up but typically a much shorter period of time

to spin down

It’s highly scalable.

If you need more injection capacity, you can keep spinning upmore instances pretty much on demand, although some cloudproviders may prefer you give them a little advance notice Inthe early days of cloud computing, my company innocentlyspun up 500 server instances for a large-scale performance testand managed to consume (at the time) something like 25 per‐cent of the total server capacity available to Western Europefrom our chosen cloud vendor Needless to say, we made animpression

It’s tooling friendly.

There are a lot of performance testing toolsets that now havebuilt-in support for cloud-based injectors Many will let youcombine cloud-based and locally hosted injectors in the sameperformance test scenario so you have complete flexibility ininjector deployment A note of caution, though: level of auto‐

mation to achieve this will vary from point-and-click to having

to provide and manage your own load injector model instanceand manually spin up/spin down as many copies as you need.And now on the minus side:

It’s not cheap.

This is particularly true if you forget to spin down your injectorfarm after that 200,000-virtual-user performance test has fin‐ished While cloud pricing models have become cheaper andmore flexible, I would caution you about the cost of leaving1,000 server instances running for 48 hours as opposed to the

intended 1 hour Think $10,000 instead of $100.

It’s not always reliable.

Something I’ve noticed about cloud computing that has neverentirely gone away is that you occasionally spin up serverinstances that, for some reason, don’t work properly It’s usuallypretty fundamental (e.g., you can’t log in or connect to theinstance) This is not too much of a problem, as you can simplyterminate the faulty instance and spin up another, but it issomething you need to bear in mind

Load injection capacity

As part of setting up the performance test environment, you need tomake sure there are sufficient server resources to generate therequired load As already discussed automated performance testtools use one or more machines as load injectors to simulate realuser activity Depending on the application technology, there will be

a limit on the number of virtual users that you can generate from agiven machine

During a performance test execution, you need to monitor the loadbeing placed on the injector machines It’s important to ensure thatnone of the injectors are overloaded in terms of CPU or Memoryutilization, since this can introduce inaccuracy into your perfor‐mance test results Although tool vendors generally provide guide‐lines on injection requirements, there are many factors that caninfluence injection limits per machine You should always carry out

a dress rehearsal to determine how many virtual users can be gener‐ated from a single injector platform This will give you a more accu‐rate idea of how many additional injector machines are required tocreate a given virtual user load

Automated performance testing will always be a compromise, sim‐ply because you are (normally) using a relatively small number ofmachines as load injectors to represent many application users In

my opinion it’s a better strategy to use as many injector machines aspossible to spread the load For example, if you have 10 machinesavailable but could generate the load with 4 machines, it’s preferable

to use all 10

The number of load injectors in use can also affect how the applica‐tion reacts to the Internet Protocol (IP) address of each incomingvirtual user This has relevance in the following situations:

Load balancing

Some load balancing strategies use the IP address of the incom‐ing user to determine the server to which the user should beconnected for the current session If you don’t take this intoconsideration, then all users from a single injector will have thesame IP address and may be allocated to the same server, whichwill not be an accurate test of load balancing and likely causethe SUT to fail In these circumstances you may need to ask theclient to modify the load balancing configuration or to imple‐

ment IP spoofing, where multiple IP addresses are allocated to

the NIC on each injector machine and the automated perfor‐mance tool allocates a different IP address to each virtual user.Not all automated performance test tools provide this capability,

so bear this in mind when making your selection

User session limits

Application design may enforce a single user session from onephysical location In these situations, performance testing will

be difficult unless this limitation can be overcome If you arelimited to one virtual user per injector machine, then you mayneed a very large number of injectors!

Certain other situations will also affect how many injectors you willneed to create application load:

The application technology may not be recordable at the middleware level

In terms of load injection, if you cannot create middleware-levelscripts for your application, you have a serious problem Youroptions are limited to (a) making use of functional testing tools

to provide load from the presentation layer; (b) making use of

some form of thin-client deployment that can be captured with

your performance testing tool—for example, Citrix ICA or MSTerminal Services RDP protocol; or (c) building some form ofcustom test harness to generate protocol-level traffic that can berecorded If you can’t take the thin-client route, then your injec‐tion capability will probably be limited to one virtual user permachine.

You need to measure performance from a presentation layer perspec‐ tive

Performance testing tools tend to work at the middleware layer,and so they have no real concept of activity local to the applica‐tion client apart from periods of dead time on the wire If youwant to time, for example, how long it takes a user to click on acombo box and choose the third item, you may need to use pre‐sentation layer scripts and functional testing tools Some toolvendors allow you to freely combine load and functional scripts

in the same performance test, but this is not a universal capabil‐ity If you need this functionality, check to see that the vendors

on your shortlist can provide it

Addressing different network deployment models

From where will end users access the application? If everybody is onthe local area network (LAN), your load injection can be entirelyLAN based However, if you have users across a wide area network(WAN), you need to take into account the prevailing network condi‐tions they will experience These primarily include the following:

Available bandwidth

A typical LAN currently offers a minimum of 100 Mb, andmany LANs now boast 1,000 or even 10,000 Mb of availablebandwidth WAN users, however, are not as fortunate and mayhave to make do with as little as 256 Kb Low bandwidth andhigh data presentation do not generally make for good perfor‐mance, so you must factor this into your performance testingnetwork deployment model

Network latency

Think of this as delay Most LANs have little or no latency, butthe WAN user is often faced with high latency conditions thatcan significantly affect application performance

Application design can have a major impact on how WAN friendlythe application turns out to be I have been involved in manyprojects where an application flew on the LAN but crawled on theWAN Differing network deployment models will have a bearing onhow you design your performance testing environment.

You may be interested to know that inherent network

latency is based on a number of factors, including

these:

Speed of light

Physics imposes an unavoidable overhead of 1 millisecond of

delay per ~130 kilometers of distance

Propagation delay

Basically the impact of the wiring and network devices such

as switches, routers, and servers between last mile and first

mile

There are tools available that allow you to model application perfor‐mance in differing network environments If significant numbers ofyour application users will be WAN-based, then I encourage you toconsider using those Typically they allow you to vary the band‐width, latency, and congestion against a live recording of applicationtraffic This allows you to accurately re-create the sort of experience

an end user would have at the end of a modest ADSL connection.You may also wish to include WAN-based users as part of your per‐formance test design There are a number of ways to achieve this:

Load injection from a WAN location

This is certainly the most realistic approach, although it is notalways achievable in a test environment You need to positionload injector machines at the end of real WAN links and simu‐late the use-case mix and the number of users expected to usethis form of connectivity as part of your performance test exe‐cution

Modify transaction replay

Some performance testing tools allow you to simulate WANplayback even though the testing is carried out on a LAN envi‐ronment They achieve this by altering the replay characteristics

of nominated use-case load-injector deployments to represent areduction in available bandwidth—in other words, slowing

down the rate of execution In my experience, there is consider‐able variation in how tool vendors implement this feature, so besure that what is provided will be accurate enough for yourrequirements.

Network simulation

There are products available that allow you to simulate WANconditions from a network perspective Essentially, a device isinserted into your test network that can introduce a range ofnetwork latency effects, including bandwidth reduction

Environment design checklist

The following checklist will help you determine how close your testenvironment will be to the production deployment From thedeployment model for the application, collect the following infor‐mation where relevant for each server tier This includes devicessuch as load balancers and content servers if they are present

Number of servers

The number of physical or virtual servers for this tier

Load balancing strategy

The type of load balancing mechanism in use (if relevant)

Hardware inventory

Number and type of CPUs, amount of RAM, number and type

of NICs

Software inventory

Standard-build software inventory excluding components of

application to be performance tested

Application component inventory

Description of application components to be deployed on thisserver tier

Internal and external links

Any links to internal or external third-party systems These can

be challenging to replicate in a test environment and are oftencompletely ignored or replaced by some sort of stub or mock-

up Failing to take them into account is to ignore a potentialsource of performance bottlenecks At the very minimum youshould provide functionality that represents expected behavior.For example, if the external link is a web service request to a

credit reference service that needs to provide subsecondresponse, then build this into your test environment You will

then have confidence that your application will perform well as

long as external services are doing their part (Make sure that

any external link stub functionality you provide is robustenough to cope with the load that you create!)

Network connectivity is usually less challenging to replicate duringtesting, at least with regard to connections between servers Remem‐ber that any load you apply should be present at the correct location

in the infrastructure For incoming Internet or intranet traffic, this istypically in front of any security or load balancing devices that may

be present

Software installation constraints

An important and often-overlooked step is to identify any con‐straints that may apply to the use of third-party software within the

test environment By constraints, I mean internal security policies

that restrict the installation of software or remote access to serversand network infrastructure These may limit the granularity ofserver and network monitoring that will be possible, and in theworst case may prevent the use of any remote monitoring capabilitybuilt into the performance test tool you wish to use

Although not normally a concern when you are performance testingin-house, such constraints are a real possibility when you’re provid‐ing performance testing services to other organizations This situa‐tion is more common than you might think and is not somethingyou want to discover at the last minute! If this situation does ariseunexpectedly, then you will be limited to whatever monitoring soft‐ware is already installed in the performance test environment

Setting realistic performance targets

Now, what are your performance targets? These are sometimes

referred to as performance goals and may be derived in part from

any service-level agreement (SLA) that may be in place Unless youhave some clearly defined performance targets in place againstwhich you can compare the results of your performance testing, youcould be wasting your time

to a third party.

Application performance testing should be an integral part of aninternal strategy for application life cycle management Performancetesting has traditionally been an overlooked or last-minute activity,and this has worked against promoting consensus on what it deliv‐ers to the business

Strategies for gaining consensus on performance testing projectswithin an organization should center on promoting a culture ofconsultation and involvement You should get interested partiesinvolved in the project at an early stage so that everyone has a clearidea of the process and the deliverables This includes the followinggroups or individuals:

The business

C-level management responsible for budget and policy decision–making:

• Chief information officer (CIO)

• Chief technology officer (CTO)

• Chief financial officer (CFO)

• Departmental heads

• Business architects (BA’s)

Remember that you may have to build a business case to justifypurchase of an automated performance testing solution andconstruction of an (expensive) test environment So it’s a goodidea to involve the people who make business-level decisionsand manage mission-critical business services (and sign thechecks!)