WebStress - InterSystems

WebStress
Bill McCormick
Fall 2011
What is WebStress
• A utility being shipped as part of the product in 2011
• A tool that allows for recording http traffic between any client
and server that supports running thru a proxy
• Tailored for CSP and Zen specifically
• Allows for customizing and/or randomizing the data being
utilized from a given recorded base script
• Can play back multiple recordings simultaneously to simulate
load and verify results, including performance metrics
• Also has applications for QD, UnitTesting and other
purposes
Why WebStress?
• TrakCare performance evaluations required for certain bids
– Brisbane
– Edinburgh
• LoadRunner and other tools for this can be very expensive
• Managing CSP / Zen based applications requires a few little
tricks to benchmark correctly
• Has been used in dozens of benchmarks since 2002
• Chile - Used to verify performance standards
• Added as a utility for use by customers in 2011.1
Some core concepts
• Controller
– Manages the playback of a test and gathers results
• Generator
– Machine that is executing the script and randomization logic
during playback. Can be same machine as controller
• WebServer
– The URL that the application is running over. In the case of a
Cache system it also allows us to connect to the server
• App Server
– The actual database being used by the test under Cache
Continued
• NoEncrypt Flag
– Sets the flag that allows benchmark recordings and
playback to work on CSP / Zen based solutions
• No Delay
– For non page content ignore recorded delays
– js, html, css, jpg etc
• No Results
– For non page content ignore results
– js, html, css, jpg simulates cacheing
Continued
• Scripts
– A collection of http requests that from a UI perspective
represent a “transaction” or “workflow”
• Tests
– A collection of scripts that when combined represent a
“server usage profile”
• Save Page Source
– For verification purposes this will loop over a script and
save the returned page content to a local directory
Recording
• WebStress has a facility that launches a listener on a defined
port
• A browser for example can be configured to use this port as
a proxy and we capture the output
• We will offer to set the no encrypt flag for a given cache
service when the listener is launched
• The recorder also generates a routine for providing
randomization logic
Recording
• Demonstrate
Customizing a Script
• Once a recording is completed we can edit it to change settings and
values or completely randomize data being used
– Parameters
• These are name value pairs that were submitted via http
– Http Headers
• This is the information your browser added to the http request when it
was POSTed or GET
– URLs
• These are the individual http requests captured. They can be removed
or manually added
• This can be done manually in the script itself or by overriding
the stubs in the generated routine.
Challenges
• Implementing the randomization logic is the most
challenging task involved in building a benchmark run
– May require a copy of the live data
– May require business logic flow to safely implement
– Must be done to generate a proper test
Creating a Test - Settings
• Controls when and how the playback of the various scripts is
launched
– Scheduled
– Start now
• Run time settings
–
–
–
–
–
–
Run time
Warm up
Cool down
Delay Mode
Page Source
Use HTTPS
Tests Continued
• Adding Scripts
– Select a Script
– Choose a Generator
– Choose a Web Server
– Define the rate
• Sessions
• Processes
– URL Loopback
– Target
• Repeat as needed
Running a Benchmark
• Preparing a Test
– Starts the processes on the Generator
– Starts the controller’s listener that drives the generators and collects
the data
• Run the Test
– The Controller sends the start signal to the generators
– Results are ignored for the duration of the “warm up”
– Live results display on this page
• After the test
– Results are processed
– Jobs Halted
Running a Benchmark
• Let’s start a test while we talk
Running a Benchmark - Cont
• While the test is running you will see information on the current Rates Per
Minute. These are color coded to indicate how close to your target for a
given script you are doing.
• If you need to you can stop a test, adjust the settings for the Sessions and
Processes and rerun the test again to aim closer to target
Debug Mode
• You have the option to run a script and have the returned pages be stored
to disk. This is very handy for debugging a script and validating that things
are performing correctly.
• To do this we specify the Source Directory and the Save Page Source
options in the test settings.
• This creates a structure at that location that represents each script, and
each time we looped thru the URLs
Running a Benchmark
• Verify our demonstration
WebStress Results
• Run History Page
• WebStress.Results.Iterations
• WebStress.Results.PageSummary
• Capture time to first byte, last byte average/max/min
• Exportable to Excel
WebStress Summary
• Runs on 2011.1
• Can be used against any http based application
• Keep Alive must be disabled during recording
• Only the tool must run on 2011.1. It can push load at any
version of Cache.
WebStress Academy
• Thank you
• Bill McCormick - bill.mccormick@intersystems.com
• Iain Bray - Lead developer - Iain.Bray@intersystems.com
WebStress
Bill McCormick
bill.mccormick@intersystems.com