Open Testware Reviews
OpenSTA (Open System Testing Architecture)
Copyright 2003 by Tejas Software
Consulting - All rights reserved.
Contents
Overview -- Maturity -- Project activity -- Platforms
-- Support -- Documentation
-- Installation -- Implementation
-- Performance -- Similar
tools -- Limitations -- Observations -- Appendix
A: Sample SCL code -- Appendix B: Replay log
Overview
Reviewed: 2003-March-27
Version reviewed: 1.4.1,
2002-July-24
Maintainer: opensta.org
URL: http://opensta.org/
Testingfaqs.org category: Load
and Performance Tools
License: GNU GPL plus others for
third-party code
User interface: GUI, command line
OpenSTA is a feature-rich GUI-based web load/performance test tool that
runs on Windows-NT class systems. It's a complex tool that takes some
time to get used to. Its design is similar to some commercial load test
tools. Unfortunately, I have to report inconclusive results from my
review. I encountered a worrisome stream of problems with the tool on
the two systems I ran it on, and based on that experience alone, I
would have to conclude that OpenSTA is not ready for broad use.
However, I heard from several people who had only minor problems, and
are very happy with OpenSTA. If any Open
Testware Reviews subscribers would like a more conclusive report,
let me know and I'll investigate further for a future issue. Here I'll
report what I know so far.
Despite the flaws I saw, I got OpenSTA working well enough to get some
satisfying crashes on the small web servers I tested with. Note that
load testing should be performed by advanced testers who have a strong
understanding of test automation, system performance, and networking.
The future of OpenSTA is in question right now because of a feud over
the ownership and maintenance of the tool. The players are Quotium
Technologies, Cyrano, Inc., and the volunteers working on the
SourceForge project. More on that below.
By the way, OpenSTA is pronounced "o'pen-stah" by most of the people
who are close to the original developers, or if you have a New England
accent, "o'pen-star." Those who aren't comfortable saying "stah"
sometimes spell out the last three letters instead.
Maturity
3 - alpha (on a scale of 1-5)
The project has listed itself on SourceForge as production quality, but
I can't justify better than an alpha rating based on my experience. If
we can better characterize a majority of the problems I found, I'd
likely bump it up to beta status.
Project activity
3 - stable (on a scale of 1-5)
The last release was in July 2002, despite a fairly significant bug
backlog. However, a pool of users and developers are reachable via the
established mailing lists, so a higher rating for Project Activity would
be justified if there were more progress on the development side. I'm
told that most of the recent development activity has been to correct
build problems.
Platforms
OpenSTA runs on Windows NT SP5, Windows 2000, and Windows XP. NT
users need Windows Installer for Windows NT 1.1. The tool needs version
2.5 or later of the Microsoft Data Access Components. The Users Guide
calls for a minimum of a Pentium 200 processor, 80MB RAM, and 20MB hard
disk space. OpenSTA supports HTTP 1.0 and 1.1, and HTTPS (SSL).
The Script Modeler directly supports using Netscape Navigator 4.7
and Internet Explorer 4, 5 and 6 for script recording, but with some
manual setup you can use any browser that supports proxies. To use the
Web Relay Daemon, you'll need a web server on your test machine that
supports ISAPI.
Support
OpenSTA uses SourceForge for mailing lists, configuration management,
and bug tracking for the project. Three mailing lists
are available -
- opensta-announce - OpenSTA project update announcements
(currently inactive)
- opensta-users - OpenSTA users discussion and support (an active
list)
- opensta-devel - OpenSTA developer discussions (a fairly active
list)
There is also the OpenSTA
forum on QAforums.com. It's not quite as active as the opensta-users
list, but I did get referred to the archives there for answers a few
times.
The following two trackers are
set up, with the counts below taken when I began my review -
- Bugs (69 open / 258 total)
- Feature Requests (16 open / 26 total)
Configuration
management is provided via CVS, with four developers currently
approved to check in changes.
Several companies offer consulting, training, or commercial support for
OpenSTA. Most of them employ one or more people who were involved in the
original development of OpenSTA. Many of the companies are in the early
stages of developing their OpenSTA service offerings, and I suspect that
few of them have any paying customers for these services.
- etest associates, based in the UK, has the only solid
offer for technical support for OpenSTA. They tell me that they plan to
offer on-site training soon. Etest associates seems to be respected by
the OpenSTA community.
- Director of Professional
Services for RTTS.
- Zebsys,
based in the UK, offers training and consulting for OpenSTA.
- Abstrakt Gmbh,
based in Germany, reportedly provides consulting services associated
with the OpenSTA tool.
- Quaver
Computing, based in the UK, offers training and consulting for
OpenSTA, some or all of which is resold from etest associates.
- Daniel Sutcliffe, the
current lead for the OpenSTA SourceForge project, tells me that he's
interested in offering OpenSTA services through his company tcNOW.com.
He's based in the U.S.
Note that the opensta.com web site has
details about OpenSTA support from Cyrano, but this site hasn't been
updated since Cyrano was restructured and a Cyrano, Inc. representative
tells me that they are not currently offering support for OpenSTA
(probably because of pending litigation).
Documentation
The main web site for OpenSTA is opensta.org.
It includes three manuals,
available in html format both online and in downloadable packages. The
manuals are:
- OpenSTA Getting Started Guide for OpenSTA 1.3
- OpenSTA User's Guide
- Script Control Language Reference Guide, also available in
French
Confusingly, the manuals refer to the tool as "HTTP/S Load", perhaps
meaning that HTTP/S Load is a particular implementation of the OpenSTA
architecture. Users all tend to refer to the toolset and architecture
collectively as OpenSTA.
The manuals have not been updated for version 1.4.1, and I did notice a
few things that were out of date in the manuals. The built-in help is
likely to be more up to date. Legend has it that Cyrano had a more
complete set of documentation, but they are not available now. In any
case, I was happy to have the fairly thorough html documentation
(including screen shots) that's available, though it is slightly out of
date and sometimes confusing.
There is also a subset of opensta.org, the OpenSTA community site, a.k.a
the OpenSTA.org portal. It includes an extensive FAQ, which I recommend
as a nice introduction and reference to the OpenSTA community, as well
as code samples from users, and links to the other various resources.
It's slated to eventually replace the opensta.org home page. Personally,
I feel that the design of the portal (and others like it) makes it look
cluttered and confusing.
There are also the two sites on SourceForge, the OpenSTA Developer Home, as well as
the OpenSTA: Summary
page where you'll find all the SourceForge resources for the project if
you can't find them linked from anywhere else. By the way, I don't
recommend using the opensta.com site because
it is no longer being maintained.
For an independent comparison of OpenSTA to seven commercial tools and
one other freeware tool, see the "Load
Test Tools Evaluation" slide set, dated March 5, 2002, by Abraham
Jacob, Riyaj Shaik, and Paul Tennis.
Installation
OpenSTA installs from a Windows msi file that's just shy of six
megabytes. Installing and uninstalling both require a reboot.
Installation is straightforward. Though the download page does not
mention support for Windows XP, I've heard that OpenSTA does run on XP.
I tested it on Windows NT SP6a and Windows 2000 SP3.
I did encounter a known issue (bug 216752) when I logged in as a user
without administrator privileges on a system with OpenSTA installed. I
got an error dialog every time I logged in with a non-administrator
account. OpenSTA was apparently trying to do some sort of user-specific
installation. The login continued without any further trouble when I
dismissed the dialog
Implementation
OpenSTA has a substantial source code base. I looked at the source
package for version 1.4.1, available as a zip file via ftp. It's about
300,000 lines of non-comment source code, mostly C++. There are about
280,000 lines of comments as well, though I'm told that most of the
comments are file headers and the code is actually not very well
documented. The OpenSTA
Build Instructions give some information about the structure of the
code, though it looks like there would be a large learning curve in
understanding any large fraction of the code simply because it's such a
large source base.
OpenSTA sources are available for download separately from the
binary installation package - the source is almost six megabytes. There
are five additional components not developed by the OpenSTA project that
must be downloaded from various web sites in order to build the tool. I
did not try to build OpenSTA from the source because it requires the
proprietary Microsoft Visual C++ compiler, which I don't have.
I didn't find any test cases for the tool. There does appear to be
some hooks for memory allocation debugging in part of the code, though
the hooks probably aren't being used.
If you want to build OpenSTA from the source, it is recommended to get
the latest sources from the CVS server rather than relying on the 1.4.1
source package.
Performance
The main performance issue with load test tools is how many virtual
users they can support on a given hardware platform. The nice thing with
an open source tool is that there are no artificial limits on virtual
users like those imposed by the typical licenses for a commercial load
test tool.
I ran some high load tests on my old workhorse, a 450 MHz Windows NT
4.0 machine with 384 MB RAM and 823 MB total virtual memory. Problems
viewing the test results prevented me from drawing any solid
conclusions. It appears that OpenSTA is capable in theory of running at
least 1000 virtual users from one machine (if you use reasonable "think
time" between each action), but I wouldn't trust that any load test
tool was doing what it said it was without a careful analysis of the
test results and resource utilization on the test console machine.
Similar tools
There are many tools available for web load testing, some of which are
listed in the Load and
Performance Tools list on testingfaqs.org. Some tools are designed
specifically for web testing, and some are general-purpose load test
tools that have support for web site testing. Note that some
special-purpose load test tools are not designed to handle web testing.
I have notes on a number of other freeware load test tools; most of
them not yet production quality. I'll publish a survey of them in a
future issue of Open Testware Reviews. There are three freeware tools
currently on the testingfaqs.org list - Microsoft Web Application
Stress Tool (WAS), Load, and TestMaker. One commercial tool worth
mentioning is QuotiumPRO,
which was originally based on OpenSTA, though Quotium Technologies
tells me that they've done a great deal of work on it since starting
with the OpenSTA base. I haven't tried it and can't specifically
recommend it over any other commercial offering, except that it may look
somewhat familiar to you if you've spent a lot of time with OpenSTA.
Limitations
I had considerable trouble trying to get OpenSTA to work. I'm puzzled,
because there are many people using the tool with much more success
than me. Problems I saw included minor usability problems, functionality
that stopped working entirely until I restarted the tool, plus a few
irreproducible crashes. I reinstalled OpenSTA several times in an
attempt to solve problems, and even that didn't always work. I couldn't
access most of the test results, so I'm not even sure my tests were
doing what they were supposed to. To see whether my problems were
isolated to version 1.4.1, I installed version 1.2.2, and I had very
similar problems there too.
I had more luck on Windows NT than Windows 2000. Major pieces of
functionality would frequently stop working on my Windows 2000 test
system, so I stuck with NT for most of my testing. I was not able to get
the NT box to marshal the resources of the Windows 2000 box to be able
to run additional tests, probably because of problems in running the
OpenSTA Name Server daemon on the Windows 2000 machine.
OpenSTA only records http requests. It can't test correct operatoin of
client-side code like javascript, Java applets, or Flash applications,
except to simply download the code to the local client via http. It
seems to try to capture ftp requests, but I was not able to
successfully retrieve a file via ftp when recording an OpenSTA script.
I was not able to log in to a secure web site using SSL while recording
a script.
I didn't have nearly enough time to isolate and report all the issues I
found. Here are the ones I did report (note that the numbers are so
large because they're global across all SourceForge projects):
699741
- Dataname can end with hyphen/underscore
699730
- Dataname first character can be nonalpha
703393
- Can't get Properties pane when Show Properties button gone
703399
- Incorrect highlighting for first row in test pane
703813
- Internal error for long input on numeric properties
703897
- Name Server aborts on startup every time I log in
707193
- Total Active Users window not functional during playback
707206
- Results windows show no data, test results unknown
707214
- No status shown for playback in Script Modeler
707220
- Gateway doesn't work for IE 5 on Windows 2000
707231
- Commander unable to run tests
Observations
If OpenSTA were to live up to its potential, it could be a nice
entry-level web load and performance test tool. A number of people are
happy with it, including a half dozen or so who sang its praises to me
directly when I asked for feedback. But I haven't been able to
reproduce that happy experience myself. As the lead developer Daniel
Sutcliffe told me, "Some installs work seamlessly, others are a
nightmare from day one." Until someone gets a handle on what causes the
nightmare scenarios, I can't predict which of these categories you'll
fall into if you try the tool.
Despite my nightmare experiences, I did get OpenSTA working well enough
to apply stress to a web server. I used the demo web site that's part of
the Getting Started Guide -- it
consists of a CGI script and a flat-file database. On one run it
crashed several instantiations of ActiveState Perl that were probably
running the CGI script. On another test run in a different
configuration, OpenSTA crashed the Windows 2000 kernel on the web
server.
OpenSTA can be used for several similar tasks that I generally lump
under the term "load testing," though the terminology varies widely in
the wild. You can use OpenSTA to measure the performance of a web
application under a specific load. You can conduct experiments to
determine the maximum number of simultaneous users you can have before
performance becomes unacceptable or some component fails. Or you can
take a stress testing approach and try to push your web site until
something catastrophic happens.
OpenSTA records tests by using a web proxy that records http traffic.
This allows the tool to be mostly browser-independent, but it doesn't
allow for testing client-side applets and scripts such as javascript,
except to capture the results of that code that result in additional
http requests. OpenSTA directly supports Netscape 4.7 and three major
revisions of Internet Explorer, in that it will launch the browser when
you start to record a test, and it will automatically set up the proxy
and turn off the home page setting so the home page doesn't get
recorded. But you can use other browsers if you manually set up the
proxy to point to port 81 on the localhost. I successfully used Opera
and Mozilla to record tests. In addition to tests, OpenSTA lets you
define "collectors" for performance metrics that can be used both in
load test mode and to monitor production systems. I'd elaborate more on
them, but these were one of the things I couldn't get to work properly.
One thing that OpenSTA doesn't account for automatically is the cache
in the browser you're using to record tests. It's important to record
with the cache turned on just like most end users will. But you have to
choose carefully when to clear the disk and memory caches, otherwise
your previous experiments could result in some web page hits not
getting recorded because they're still in the cache. This is especially
a concern if you leave the browser running after recording, and then
re-record a script. The same reasoning could apply to cookies, including
non-persistent cookies if you don't close the browser in between
recording each test.
Tests are recorded using Script Control Language (SCL), which reminds
me of Fortran and COBOL. The language traces its roots to the commercial
V-TEST and Cyrano Test tools. I would have preferred that the tool
embedded an existing scripting language rather than using a unique
language that's only relevant for a few tools. Anyway, testers may
"model" a script after recording it by adding variables and data lists
that gives different data for each virtual user to use, so the tests
don't all do exactly the same thing. I parameterized one of the scripts
that I recorded so that I could specify the host name for the web
server. Learning how to do this wasn't trivial, because the SCL
documentation doesn't thoroughly explain the different ways that
variables can be accessed. I also was not able to completely "model"
the script so that each virtual user used a different login account
using the documentation in the Getting
Started Guide, because it did not explain how to use the
variables.
OpenSTA claims to be able to spread tests across several servers, in
order to generate a high load. I wasn't able to get this to work on my
configuration, though others report to have it working.
The OpenSTA community is in turmoil right now. OpenSTA was originally
developed by Cyrano SA. Cyrano SA went bankrupt and their French
headquarters was acquired by Quotium Technologies, supposedly along with
all of Cyrano's intellectual property. Cyrano had a UK site that was
liquidated, though the former employees still have some involvement with
OpenSTA at other companies. The U.S. site still exists as a separate
entity, Cyrano, Inc., which is arguing with Quotium Technologies over
ownership of OpenSTA and other tools developed by Cyrano. On top of
that, there was a recent dispute between the volunteer OpenSTA
developers and Quotium. Quotium is now planning to fork the source base
and distribute their own version of OpenSTA.
The licenses that apply to the binary distribution of OpenSTA are the
GNU GPL, GNU LGPL, Original SSLeay License, and the UCD-SNMP Conditions.
The OpenSTA source is licensed under the GNU GPL, and the others come
from the third-party code that is built along with the core OpenSTA code.
Appendix A: Sample SCL code
Here is the script I recorded while doing the exercise in the Getting Started Guide, using the
"Which US President" sample web site. I added the HOST and URLBUF
variables so I could easily change the target web server. Besides those
changes, the code is exactly as OpenSTA produced it when I captured the
test.
!Browser:IE5
!Date : 3/17/03
Environment
Description ""
Mode HTTP
Wait UNIT MILLISECONDS
Definitions
! Standard Defines
Include "RESPONSE_CODES.INC"
Include "GLOBAL_VARIABLES.INC"
CHARACTER*512 USER_AGENT
CHARACTER*256 MESSAGE
Integer USE_PAGE_TIMERS
Timer T_FINDBYNAME
CHARACTER*1024 cookie_2_0
CHARACTER*1024 cookie_3_0
CHARACTER*1024 cookie_4_0
CONSTANT DEFAULT_HEADERS = "Host: 192.168.1.113:8080^J" &
"User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)"
CONSTANT HOST = "thinkpad:8080"
CHARACTER*1024 URLBUF
Code
!Read in the default browser user agent field
Entry[USER_AGENT,USE_PAGE_TIMERS]
Start Timer T_FINDBYNAME
SET URLBUF = "http://" + HOST + "/cgi-bin/findpres.plx HTTP/1.0"
PRIMARY GET URI URLBUF ON 1 &
HEADER DEFAULT_HEADERS &
,WITH {"Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms" &
"-excel, application/vnd.ms-powerpoint, application/msword, */*", &
"Accept-Language: en-us", &
"Connection: Keep-Alive"}
DISCONNECT FROM 1
WAIT 9404
SET URLBUF = "http://" + HOST + "/cgi-bin/findpres.plx HTTP/1.0"
PRIMARY POST URI URLBUF ON 2 &
HEADER DEFAULT_HEADERS &
,WITH {"Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms" &
"-excel, application/vnd.ms-powerpoint, application/msword, */*", &
"Referer: http://192.168.1.113:8080/cgi-bin/findpres.plx", &
"Accept-Language: en-us", &
"Content-Type: application/x-www-form-urlencoded", &
"Connection: Keep-Alive", &
"Content-Length: 18", &
"Pragma: no-cache"} &
,BODY "loginid=a&passwd=a"
Load Response_Info Header on 2 &
Into cookie_2_0 &
,WITH "Set-Cookie,findpresid"
DISCONNECT FROM 2
WAIT 6990
SET URLBUF = "http://" + HOST + "/cgi-bin/findpres.plx HTTP/1.0"
PRIMARY POST URI URLBUF ON 3 &
HEADER DEFAULT_HEADERS &
,WITH {"Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms" &
"-excel, application/vnd.ms-powerpoint, application/msword, */*", &
"Referer: http://192.168.1.113:8080/cgi-bin/findpres.plx", &
"Accept-Language: en-us", &
"Content-Type: application/x-www-form-urlencoded", &
"Connection: Keep-Alive", &
"Content-Length: 23", &
"Pragma: no-cache", &
"Cookie: "+cookie_2_0} &
,BODY "np=washington&pp=&re=&dz=ok"
Load Response_Info Header on 3 &
Into cookie_3_0 &
,WITH "Set-Cookie,findpresid"
DISCONNECT FROM 3
WAIT 4817
SET URLBUF = "http://" + HOST + "/cgi-bin/findpres.plx?loginid=a&logout=ok HTTP/1.0"
PRIMARY GET URI URLBUF ON 4 &
HEADER DEFAULT_HEADERS &
,WITH {"Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms" &
"-excel, application/vnd.ms-powerpoint, application/msword, */*", &
"Referer: http://192.168.1.113:8080/cgi-bin/findpres.plx", &
"Accept-Language: en-us", &
"Connection: Keep-Alive", &
"Cookie: "+cookie_3_0}
Load Response_Info Header on 4 &
Into cookie_4_0 &
,WITH "Set-Cookie,findpresid"
DISCONNECT FROM 4
SYNCHRONIZE REQUESTS
End Timer T_FINDBYNAME
Exit
ERR_LABEL:
If (MESSAGE <> "") Then
Report MESSAGE
Endif
Exit
Appendix B: Replay log
The log below is the result of playing back the script from Appendix A
in the Script Modeler.
!Begin replay
1-1 :[32]:START TIMER: T_FINDBYNAME
1-1 :[33]:SET VARIABLE: URLBUF to value http://thinkpad:8080/cgi-bin/findpres.plx HTTP/1.0,Index
1-1 :[34]:REQUEST(1): GET http://thinkpad:8080/cgi-bin/findpres.plx HTTP/1.0
1-1 :[41]:DISCONNECT(1)
1-1 :[41]:Connection 1: receiving results with status 200
1-1 :[43]:WAIT : Delay: 9404
1-1 :[45]:SET VARIABLE: URLBUF to value http://thinkpad:8080/cgi-bin/findpres.plx HTTP/1.0,Index
1-1 :[46]:REQUEST(2): POST http://thinkpad:8080/cgi-bin/findpres.plx HTTP/1.0
1-1 :[58]:Connection 2: receiving results with status 200
1-1 :[58]:HTTPRESPONSE(2): Parsing header contents. Name: COOKIE_2_0 Identity: Set-Cookie,findpresid
1-1 :[58]:HTTPRESPONSE(2): Setting COOKIE_2_0 to 'findpresid=a,1048775818'
1-1 :[62]:DISCONNECT(2)
1-1 :[64]:WAIT : Delay: 6990
1-1 :[66]:SET VARIABLE: URLBUF to value http://thinkpad:8080/cgi-bin/findpres.plx HTTP/1.0,Index
1-1 :[67]:REQUEST(3): POST http://thinkpad:8080/cgi-bin/findpres.plx HTTP/1.0
1-1 :[80]:Connection 3: receiving results with status 200
1-1 :[80]:HTTPRESPONSE(3): Parsing header contents. Name: COOKIE_3_0 Identity: Set-Cookie,findpresid
1-1 :[80]:HTTPRESPONSE(3): Setting COOKIE_3_0 to 'findpresid=a,1048775826'
1-1 :[84]:DISCONNECT(3)
1-1 :[86]:WAIT : Delay: 4817
1-1 :[88]:SET VARIABLE: URLBUF to value http://thinkpad:8080/cgi-bin/findpres.plx?loginid=a&logout=ok HTTP/1.0,Index
1-1 :[89]:REQUEST(4): GET http://thinkpad:8080/cgi-bin/findpres.plx?loginid=a&logout=ok HTTP/1.0
1-1 :[98]:Connection 4: receiving results with status 200
1-1 :[98]:HTTPRESPONSE(4): Parsing header contents. Name: COOKIE_4_0 Identity: Set-Cookie,findpresid
1-1 :[98]:HTTPRESPONSE(4): Setting COOKIE_4_0 to 'findpresid=,0'
1-1 :[102]:DISCONNECT(4)
1-1 :[104]:SYNCHRONIZE
1-1 :[104]:All requests synchronised.
1-1 :[106]:STOP TIMER: T_FINDBYNAME
1-1 :[107]:TRcrdExit, step 0: Cancelled all requests. Now waiting for the terminating script requests to complete.
1-1 :[107]:TRcrdExit, step 1: Script requests completed. Disconnecting all clients.
1-1 :[107]:TRcrdExit, step 2: Script clients disconnected.
1-1 :[107]:TOF execution is over.
!Script Completed Successfully.