Performance Testing

for
Web Applications

March 2018

1
 Web Application Performance Testing
Performance Test Process

HTTP Protocol Basics

Scripting

2
 Performance Test Process
 Discovery and Planning

 Preparation

 Execution

 Reporting

3
 Discovery and Planning
Agree on:

 Requirements

 Test scripts

 Transaction volumes

 Test scenarios

 Test data

4
 Discovery and Planning
Agree on:

 Execution environment

 Roles and responsibilities

 Test schedule

5
 Discovery and Planning
Use the information to produce a Performance Test Plan

6
 Preparation
 Create test scripts

 Create or extract test data

 Engage support personnel

 Install and/or configure tools and monitoring

7
 Execution
 Run tests according to the schedule

 Notify support personnel and stakeholders when a test is running

 Report results of the test

 Raise any defects if required

8
 Execution – Performance Tuning
 Scientific process

 Create a theory as to the cause of the performance problem using all

 Devise a test or application change to test that theory

 Execute the test to determine whether the theory is correct

 Repeat the process until the problem is resolved

9
 Reporting
 Write the report assuming that recipients will only read the executive
summary

 The rest of the report is evidence to justify what is written in the executive
summary

 Make the wording as clear and simple as possible

10
 Reporting
 What did the test do: number or users, transactions per second

 What was the result: response times, server utilisation

 Was this good enough: did it meet SLAs

 What might be the cause of any problems: ran out of a resource, used too
much of a resource

11
 HTTP Protocol
 Request / Response protocol

 All communications are initiated by a request

 All requests receive a single response*

 There is no way for a server to initiate a message – but there are several
ways to simulate it

12
 URL Structure

protocol://server:port/path/file.ext?parameter=value&parameter2=value2

https://www.austrade.gov.au/search.aspx?ModuleID=8367&keywords=livestock
%20export&multiSite=False

13
 URL Structure - Protocol

HTTP – no encryption

or

HTTPS – connection is encrypted between the client and the server

14
 URL Structure - Port

It can be any number from 1 to 65,535

If it is not specified then the default port is used

The default port for HTTP is 80

The default port for HTTPS is 443

15
 Request Methods - Get

The original web request type

The start of all web interaction

Typically only a Header with no Body

16
 Request Methods - Post

Originally created for HTML forms

Has a Header and a Body

Can be created without a HTML form e.g. via Javascript

Commonly used by web applications

17
 Request Methods – Unicorns

Options – Returns a list of supported methods

Head – Returns only the Header and not the body

Put – Send a file to the server

Delete – Delete a file from the server

18
 HTTP Status Codes

1xx – Informational

2xx – Successful

3xx – Redirection

4xx – Client Error

5xx – Server Error

19
 Encoding

Problem: The web server needs to be able to determine the difference between

syntax and data

Solution: Data Encoding

i.e. add more syntax to mark any syntax characters as data

20
 HTML Encoding

Syntax Characters: < > / \ ;

Escape Character: &

Examples:

>  &gt;

<  &lt;

&  &amp;

21
 URL Encoding

Syntax Characters: \ : ; ? = & space

Escape Character: %

Examples:

space  + or %20

%  %25

=  %3D

22
 C / Java / Javascript String Encoding

Syntax Characters: “ NULL

Escape Character: \

Examples:

“  \”

\  \\

CR  \r

23
 Base 64 Encoding

Only uses letters, numbers and =

Converts 3 source characters into 4 encoded characters

Often ends in one or more = characters

Example:

ABCD1234  QUJDRDEyMzQ=

24
 multipart/form-data

Uses Content-Type header to specify a non-standard field separator

Field separator is a random string

The field separator is chosen so that it never occurs in the data

Often used to upload files

25
 multipart/form-data
Example:
Content-Type: multipart/form-data; boundary=H0kKzlo9
--H0kKzlo9
Content-Disposition: form data; name=“Username”

U217913
--H0kKzlo9
Content-Disposition: form data; name=“Password”

ABCD1234
--H0kKzlo9--

26
 Cookies
 A text string sent by a web server and stored by the browser

 The browser sends it back in the header for every subsequent request to that
server

 Cookies can be set by a HTTP response header or by Javascript

27
 Cookies
 Session cookies exist only during a browser session

 Permanent cookies are stored for future browser sessions

 Permanent cookies can have short or long expiry periods

28
 Caching – Cache-Control
 Web servers send a Cache-Control header to tell the client and intermediate
proxies how to cache the resource

29
 Caching – Cache-Control
 Cache-Control:public
Any proxies can cache the resource

 Cache-Control:private
Proxies should not cache the resource

 Cache-Control:no-cache
Always check with the server to see if there is a newer version

 Cache-Control:no-store
Do not cache the resource

30
 Caching – Expires
 Web servers send an Expires header with the timestamp when the resource
is no longer valid

 If the timestamp hasn’t expired then the browser will use the copy stored in
the cache and no communication will occur with the web server

 If the timestamp has expired then the resource will be requested from the
server again

31
 Caching – max-age
 Web servers send a max-age field in the Cache-Control header with the
amount of time in seconds before the resource is no longer valid

 If the maximum age hasn’t been reached then the browser will use the copy
stored in the cache and no communication will occur with the web server

 If the maximum age has been reached then the resource will be requested
from the server again

 If max-age and Expires are specified then max-age will be used

32
 Caching – Last Modified
 Web servers send a Last Modified header with the timestamp when the
resource was last modified

 The browser sends the timestamp back in the If-Modified-Since header for
every subsequent request for that resource

 If the resource hasn’t changed then the server responds with 304 Not
Modified and the browser will use the copy stored in the cache

 If the resource has changed then a new version of the resource will be
returned with a new Last Modified header

33
 Caching – ETag
 Web servers send an ETag header with a MD5 hash of the resource

 The browser sends the ETag back in the If-None-Match header for every
subsequent request for that resource

 If the resource hasn’t changed then the server responds with 304 Not
Modified and the browser will use the copy stored in the cache

 If the resource has changed a new version of the resource will be returned
with a new ETag header

34
 Redirects
 Server responds with a 301, 303 or 307 HTTP response code

 The Location header in the response has the location of the new page

 The browser automatically sends a Get for the page in the location header

 There may be multiple redirects in a row

35
 AJAX

 Asynchronous Javascript And XML

 Allows the page to be modified without requesting the whole page again

 Javascript requests data from the web server without getting a new page

 The response XML is used by Javascript to modify the page

 JSON is becoming more common than XML but the process works the same

36
 (Psuedo-)Push Messages
 Client polling

 Long poll

 Long response

37
 (Psuedo-)Push Messages – Client Polling
 Client polls for updates based on a timer

 Can cause excessive load on the server as the client may request updates
when no changes have occurred

 Need to balance frequency of polling against load on the server

38
 (Psuedo-)Push Messages – Long Poll
 Client sends a request

 Server responds only when there is an update

 Client immediately sends another request as soon as it receives an update

 Client may timeout it there is no update for an extended period

39
 (Psuedo-)Push Messages – Large Response
 Client requests an update

 Server sends a ‘large’ response size that doesn’t complete

 Server sends some more of the response whenever there is an update

40
 Script Types

 Protocol Scripts

 GUI Scripts

41
 Protocol Scripts
 Emulate usage of the application by sending HTTP requests

 Have a low overhead on load generators so many can run on one server

 Can be extremely difficult and time consuming to create

 Requires an intimate understanding of the HTTP interaction between the

42
 GUI Scripts
 Emulate usage of the application by interacting with the browser

 Have a very high overhead on load generators so only few can run on one
server

 Measures the whole transaction including client processing time

 Can be faster to create than Protocol scripts but in many cases can be slower

 Can be less reliable than Protocol scripts and may require much more error
handling.

43
 Protocol Scripts vs GUI Scripts
Only use GUI scripts when:

 It is impractical or very time consuming to use protocol scripts

 You have a low number of concurrent users

44
 Script Recording
 Web Browser Hooking

 Browser Add-in

 Proxy

 HAR file

45
 Script Recording
 Only requests are recorded

 Need to add transactions or comments to match user actions to HTTP

46
 Correlation

 Usually a script that is recorded will not play back without changes

 Data that always changes e.g. session id

 Data that is entered e.g. user id

 Data that changes over time e.g. timestamps

 Data that changes with the application e.g. build id

 Application flow changes due to data

47
 Correlation
 These changes are dealt with by capturing the response from the server and
using it to modify subsequent requests

 This where you typically spend most of your time when creating protocol
scripts

 Comparing 2 recordings which use different data can be a good way to

48
 Correlation
 Determine the field that you wish to correlate

 Try to find it in a previous response from the server

 Modify the script to capture the field as a parameter

 Replace all occurrences of the value with the parameter

49
 Correlation
 What if I can’t find the field in a previous response?

 Check whether the field is broken over a line

 Check whether the field is encoded

 Look for the field name rather than the value

 Use a Javascript debugger to trace through the Javascript to see where the
field is getting created

50
 Correlation
 Boundaries

 Regular Expression

 Xpath

51
 Validation
 Most tools will automatically error based on HTTP 4xx and 5xx responses

 Requires some level of application knowledge and educated guesswork

 Find something that is always in a success but never in a failure

 Find something that is always in a failure but never in a success

 Every transaction should have some validation

 Correlation can count as validation

52
53