On Thu, 21 Sep 2000, Adi wrote: > It took a little longer than planned, but here it is. It is a Perl API to > the Apache ab tool. It took so long because we added a number of useful > features, mainly the ability to benchmark sequences of URLs instead of just > one. Very nice Adi! > Before I upload it to CPAN, are there any objections to calling it > "ApacheBench"? Other names I considered are "Bench", "ab", "ABuse"... but > ApacheBench I thought was the best because an m/Apache/ search on CPAN will find > it. That's the proper name, since it's a glue code for ab, plus extra fuctionality. The only thing I'd add is a prefix so we could put other Benchmarking implementation under the same tree. Especially as you have mentioned in the pod it's not mod_perl specific. I'd go for HTTPD::Bench:: or HTTPDBench:: tree. But you have already released it on CPAN, so I don't know... (I couldn't reply earlier since I was preaching mod_perl at YAPC::Europe, which was a very cool conference :) > Stas, hopefully I'll be able to integrate this with your new Apache::Benchmark > module. I haven't had time to look over yours fully, but I'm thinking your > module will be a layer around this. Currently Apache::Benchmark uses ab, > right? This module almost completely replaces ab. There are a few features > that still need to be added. Yup, cool. In fact you are welcome to take over it :) Apache::Benchmark shouldn't be depenfing on the actual engine used for Benchmarking. One should be able to plug any engine instead of ab. > Here are the first few sections of the manual. Download the full package at > http://adiraj.org/sw/ApacheBench/ApacheBench-0.5.tar.gz. Enjoy. > > -Adi > > --- > > NAME > ApacheBench - Perl API for Apache benchmarking and > regression testing. > > SYNOPSIS > use ApacheBench; > > my $b = ApacheBench->new; > > # global configuration > $b->config({ > concurrency => 5, > priority => "run_priority", > }); > > # add sequence(s) of URLs to request > $b->add({ > repeat => 10, > cookie => ["Login_Cookie=b3dcc9bac34b7e60;"], > urls => ["http://localhost/one", > "http://localhost/two"], postdata => [undef, undef], > order => "depth_first", > }); > > my $regress = $b->execute; > > # calculate hits/sec == ($#urls+1)*$n*1000 / total_time > print (2*10*1000/$regress->{"total_time"})." req/sec\n"; > > # dump the entire regression hash (WARNING, this could be a LOT OF > DATA) > use Data::Dumper; > my $d = Data::Dumper->new([$regress]); > print $d->Dumpxs; > > GOALS > This project is meant to be the foundation for a complete > benchmarking and regression testing suite for an advanced, > transaction-based mod_perl site. We need to be able to > stress our server to its limit while also having a way to > verify the HTTP responses for correctness. Since our site > is transaction-based (as opposed to content-based), we > needed to extend the single-URL ab model to a multiple-URL > sequence model. > > ApacheBench is based on the Apache 1.3.12 ab code > (src/support/ab.c). > > Note: although this tool was designed to be used on an > Apache mod_perl site, it is generally applicable to any > HTTP-compliant server. Beware, however, that it sends a > high volume of HTTP requests in a very short period of > time, which may overwhelm some weaker HTTP server > platforms like NT/IIS. > > DESCRIPTION > ApacheBench sends sequences of HTTP requests to an HTTP > server and keeps track of the time taken to receive a > response, the data that was returned, the size of the data > that was returned, and various other bits of information. > > Since it is implemented in C, it sends HTTP requests in a > tight loop which can stress your server to 100% capacity, > especially if invoked in multiple concurrent instances. > It gives accurate time measurements down to the > millisecond for each HTTP request-response interval. > > Included is a simplified re-implementation of ab using the > ApacheBench Perl API. This should help get you started > with ApacheBench. > > METHODS > new() > The constructor. It takes no arguments. > > config({ %global_params }) > Global configuration method. Should only be invoked > once, else previous configuration parameters will be > clobbered. See the global configuration section for > details on how %global_params should be structured. > > add({ %run_params }) > Run configuration method. Can be invoked multiple > times. Each invocation will register a new benchmark > run to be executed. See the run configuration section > for details on how %run_params should be structured. > > execute() > The execute method takes no arguments. It will send > the HTTP requests and return a hash reference to the > regression data. > > _____________________________________________________________________ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perlmonth.com perl.org apache.org