Re: Performance analysis questions
Simon E Spero <ses@tipper.oit.unc.edu>
Errors-To: listmaster@www0.cern.ch
Date: Wed, 18 May 1994 04:46:11 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9405180032.AA20312@tipper.oit.unc.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: ses@tipper.oit.unc.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Simon E Spero <ses@tipper.oit.unc.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Performance analysis questions
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
>>>>> "Alan" == Alan Batie <batie@ibeam.jf.intel.com> writes:
Alan> I'm about to do some server/os/platform benchmarking, and
Alan> the following issues come to mind:
I've been doing a lot of work on benchmarking http servers, so I might
as well share my experiences.
I have written a program called web-killer for systems with posix compliant
threads. web-killer takes as arguments a list of partial urls with their
relative frequencies, a host/port to connect to, and paramaters indicating
the number of concurrent sessions to start, plus the number of queries
each session should generate.
The program starts the appropriate number of threads; the threads then
randomly generate queries according to the frequency distribution pattern
supplied.
For my test frequencies, I've been using 7 months of log data from sunsite; the
test servers have been pointing at the sunsite data area. I haven't been
using inter-query separation information from the logs, as unfortunately that
is dependent on the system load, not the rate of query arrival.
The methodology has a few flaws;
Firstly, more URLs occur in load groups; when
one of the files is accessed, it will immediately trigger several more load
requests; this is not reflected in the query generator (and since I'm about
to start optimising for this, I'm bloody well going to benchmark it :-)
Secondly; queries are generated from a single machine, so logging may not be
a factor. Also, slowness on the generating machine may affect the results.
I've been using this program to test the multi-threaded httpd I'm writing
for solaris, and the results are pretty good; despite discovering some
really nasty bugs in Solaris 2.3, not all of which are fixed, I can get
average response times up to 100 times better than ncsa httpd under sunos
4.1.3 for the proof of concept version (i.e. without smart caching and
pre-fetch). (Oh, and for those of you thinking of using cached NFS for
web data; I don't recommend it.) TCP/IP on solaris 2.4 is a lot lot better than
2.3, so most of the performance leaks should go away.
Simon
----
Available for hire after July 31st | ses@unc.edu
-------------------------------------------------------------------------------
I have heard the routers pinging, each to each. | Tel: +1-919-962-9107,
I do not think that they will ping to me- | Fax: +1-919-962-5604