← Back to branch summary

~ubuntu-branches/ubuntu/breezy/ace/breezy

« back to all changes in this revision

Viewing changes to apps/JAWS/clients/WebSTONE/doc/webstone2.html

  • Committer: Bazaar Package Importer
  • Author(s): Adam Conrad, Benjamin Montgomery, Adam Conrad
  • Date: 2005-09-18 22:51:38 UTC
  • mfrom: (1.2.1 upstream) (2.1.1 sarge) (0.1.2 woody)
  • Revision ID: james.westby@ubuntu.com-20050918225138-seav22q6fyylb536
Tags: 5.4.7-3ubuntu1
[ Benjamin Montgomery ]
* Added a patch for amd64 and powerpc that disables the compiler
  option -fvisibility-inlines-hidden

[ Adam Conrad ]
* Added DPATCH_OPTION_CPP=1 to debian/patches/00options to make
  Benjamin's above changes work correctly with dpatch.

Show diffs side-by-side

added added

removed removed

Lines of Context:
apps/JAWS/clients/WebSTONE/doc/webstone2.html
1
 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
2
 
<HTML VERSION="2.0">
3
 
<HEAD>
4
 
<!-- webstone2.html,v 1.2 2000/06/04 22:00:03 brunsch Exp -->
5
 
<!-- WEBMAGIC VERSION NUMBER="2.0.1" -->
6
 
<!-- WEBMAGIC TRANSLATION NAME="ServerRoot" SRC="/var/www/htdocs/" DST="/" -->
7
 
<!-- WEBMAGIC TRANSLATION NAME="ProjectRoot" SRC="./" DST="" -->
8
 
<TITLE>What is Webstone 2.0</TITLE>
9
 
</HEAD>
10
 
<BODY>
11
 
<CENTER><H1 ALIGN="CENTER"><IMG SRC="webstone.gif" WIDTH="534" HEIGHT="174" SGI_FULLPATH="/disk6/WebStone-2.0/doc/webstone.gif"></H1>
12
 
</CENTER><H1>Introducing WebStone 2.0</H1>
13
 
<P>WebStone 2.0 is the second generation Webstone web server benchmark. It
14
 
incorporates numerous bug fixes, modifications for compatibility with other
15
 
platforms and adds the new functionality of benchmark proxy servers, cgi
16
 
and NSAPI programs as well as introducing run rules which should make Webstone
17
 
numbers significantly more meaningful for comparison.</P>
18
 
<H2>New Features</H2>
19
 
<P>Webstone 2.0 provides facilities for benchmarking proxy servers. This is
20
 
accomplished by putting in a value for the the PROXYSERVER entry in the
21
 
conf/testbed file, and changing the filelist to include URL's that have
22
 
the hostname for the actual web server.</P>
23
 
<P>Dynamic content benchmarking is now explicitly supported in Webstone 2.0.
24
 
The file README.DynamicWorkload has directions for testing of NSAPI. The
25
 
included filelist.dynamic-{light,medium,heavy} serve as sample loads, with
26
 
the filelist.dynamic-heavy being the load that should be reported for NSAPI
27
 
performance. The cgi-send numbers should be quored for the filelist.cgi-heavy
28
 
fileset.</P>
29
 
<P>A port of the WebStone 2.0 benchmark to Windows NT is also included in this
30
 
release. This port is still in progress, so full functionality is not assured.
31
 
Specifically only the benchmark code has been ported - the supporting scripts
32
 
have not.</P>
33
 
<H2>Run Rules</H2>
34
 
<P>As of Webstone 2.0, there are now run rules which must be adhered to for
35
 
published Webstone numbers. These are fairly basic, but they provide important
36
 
constraints on the benchmarking which make Webstone numbers more meaningful.</P>
37
 
<P><B>Fileset: </B>Included in the Webstone distribution is filelist.standard, which was previously
38
 
called filelist.sample. This filelist has a distribution of fileset sizes
39
 
that matches the kind of distributions seen in live web sites. The largest
40
 
file in the distribution is a 5 MB in length, which simulates the occasional
41
 
MPEG or other animation file which is downloaded. This filelist should be
42
 
used for all published Webstone numbers. Note that running WebStone 2.0
43
 
with the sort of fileset given in WebStone 1.1 will not yield a comparable
44
 
benchmark. In general, the WebStone 2.0 filelist will yield lower rates
45
 
for connections/second, but higher rates for throughput - the two sets of
46
 
numbers cannot be compared.</P>
47
 
<P>When reporting NSAPI numbers, the filelist.dynamic-heavy filelist should
48
 
be used. For CGI numbers, the filelist.cgi-heavy filelist should be used.</P>
49
 
<P><B>Benchmark Run Configuration:</B> For a reported WebStone run, the runtime must be set at least 10 minutes.
50
 
This provides adequate time for the server and client configuration to reach
51
 
a steady state, and then provides a length of time long enough to cancel
52
 
out the high variations seen in the first few minutes of the run. The number
53
 
of clients should also vary from 20 to 100 in increments of 10 so that performance
54
 
of the server under a wide variety of loads can be observed.</P>
55
 
<P><B>Server Configuration:</B> The number of threads/processes is open to the discretion of the benchmarkers.
56
 
However, whether server side logging is on must be explicitly reported.
57
 
When logging is turned on, it must be in the common logfile format, and
58
 
only IP addresses should be logged. Parsed HTML is recommended to be turned
59
 
off.</P>
60
 
<P>Proxy Configuration: The configuration of how often the proxy server polls
61
 
the actual server for refreshes of it's cache should be described, as well
62
 
as any information</P>
63
 
<P><B>Server Machine Configuration:</B> When reporting runs, it is necessary that the operating system, memory
64
 
configuration and any special operating system modifications be reported,
65
 
especially changes to the TCP/IP stack.</P>
66
 
<P><B>Testbed configuration: </B>Reported runs must include information about the network topology being
67
 
used, as well as the number and type of machines generating load.</P>
68
 
<P>All reported runs must include the information summarized by webstone -results,
69
 
excluding the timestamp. This includes: number of clients, connections per
70
 
second, little's law number, latency, error level and throughput. Preferably
71
 
in a table format.</P>
72
 
</BODY>
73
 
</HTML>