The scenario definition file is an XML file which determines all the parameters which are needed in the experiment. The XML format was chosen because of its multiples advantages:
The OpenLC scenario definition files are evolving rapidly, getting richer in features and parameters. This is because they have to adapt constantly to the new features coming up in the OpenLC server. So, don't expect to have always the same tags in the scenario. However, their definition will significantly freeze as OpenLC approaches his stable release (1.0), while I'll try hard to keep these changes under a minimum. No DTD's are defined at this moment (most probably will be in the next release).
Right now, three different XML scenario files are implemented (and are coming in future releases). One is used for define a Local experiment, other for a HTTP load experiment and the third for a IMAP4 experiment. Before to state the differences, we will start with a brief explanation to the general parameters which are common to all the scenarios.
Let's return again to the XML file used in the section 3.1. We will comment it by signalling the main properties for each of the XML tags in the file1). When the tags are not general it will be noted.
Let's start from the beginning.
<configuration> <clients number="5"></clients> <time max="5"></time> <sample small="yes" period="2.0"></sample> <!-- The number of bins of the resulting reduced data --> <reduction minElementsPerBin="10" maxBins="100"></reduction> . . . </configuration>
As you see, the file always start by a <configuration> tag and is closed by his counterpart </configuration>. Those tags are mandatory and signals the start and the end of the document (this is called the root element).
Let's see the tags which are direct descendents of configuration tag:
<runProtocol name="Local" mode="random"> <iterations max="1000"></iterations>
This tag marks the start of a protocol definition. That is, the data values we want to save, the maximum iterations, groups of commands and, of course, the proper commands we want to issue in order to refine the scenario in the protocol context, so we can properly call this a subscenario. Some subscenarios are very simple ones (i.e., Local), but, in general, they may be very rich in subtags and attributes depending on the internal servers to deal with.
Now, we will explain the main characteristics for some runProtocol components:
<retValues> <wallClock units="s" sta="mean" typecode="Float"></wallClock> <timeSpent units="s" spyplot="yes" sta="vds" typecode="Float"></timeSpent> <dataTransferred units="KB" sta="vds" typecode="Float"></dataTransferred> <commandNumber units=" " typecode="Int"></commandNumber> <threadNumber units=" " sta="minimal" typecode="Int"></threadNumber> </retValues>
This tag selects the variables we want to save for each transaction. In this example, we can choose between the next variables (but this may depend on the internal server implementation used for the protocol):
In the retValue's subtags, we see that we have some attibutes to specify more clearly its properties.
The <cmdGroup> tag groups several command (<cmd>) tags to form "atomic" actions to be done. The runProtocol.mode variable described above doesn't interfere inside this groups, where the execution is guaranteed to be sequential. This feature is perfect to simulate a Web shopping procedure, IMAP4 procedure call sequence or, in general, a group of actions you want to ensure they will always be done sequentially. Also, the microkernel do command group statistics based on this tag grouping.
It has only one attribute for the moment:
<cmd spy="yes" name="constant"> constant(range=0.01) </cmd> <cmd spy="no" name="random"> random(range=0.01) </cmd> <cmd spy="yes" name="linear"> linear(range=0.01) </cmd> </cmdGroup> </runProtocol> </configuration>
Finally, here we have the most internal tag for <runProtocol>, the <cmd> tag. Here goes all the stuff related with the actual commands issued by the internal servers to attack (or just simulate this, in the case of Local protocol) exterior IT servers. It has several components:
In the next section, we will have a more-in-depth look into the different sub-scenarios currently implemented in the OpenLC server.
In the last section we have made a description on the general tags for OpenLC scenarios. But one of the OpenLC's strengths is the flexibility to adapt to an array of stress testing situations. In this section we will discuss the different XML subscenarios for the internal servers present in the OpenLC server.
The Local scenario is implemented as a stand-alone and synthetic test. It is very useful to simulate runs and the user is offered the capability to control a variety of parameters to test the OpenLC capabilities (for example, how many transactions per second can deal with), to quickly design and test new clients, or just to learn using it.
In this subscenario, the only components which are different from the general format are the Local server internal API. Right now there are three procedures:
All this procedures also return a dataTransferred retValue which is simply the time spent by the sleep call multiplied by a factor (right now 1024).
Like the Local protocol, no special tags are needed, and the only procedure implemented right now on the HTTP internal server API is get.
The support for the IMAP4 protocol adds a couple of tags in order to authenticate the users before doing any transaction. The tags are:
The IMAP4 internal server connects to auth.host and authentifies each thread with an user.name identifier. The map between the threads and usernames is made using a round-robin algorithm. If there are more clients than user names, several clients use the same username (some IMAP4 server support until 4 sessions with the same user). If there are more usernames that clients, there will remain usernames unused.
The IMAP4 internal server API is basically the same supported by the imaplib Python module (see http://www.python.org/doc/lib/module-imaplib.html. Right now, an effort is made to compute the dataTransferred (retValue) value, but take this as an aproximation until a better algorithm is implemented.