Adi wrote:
>
> "Christopher L. Everett" wrote:
> >
> > Adi wrote:
> > >
> > > martin langhoff wrote:
> > > >
> > > > Chris,
> > > >
> > > > i'd bet my head a few months ago someone announced an apache::bench
> > > > module, that would take a log and run it as a benchmarking secuence of
> > > > HTTP requests. just get to the list archives and start searching with
> > > > benchmarks and logs. CPAN is your friend, also.
> > >
> > > It was HTTPD::Bench::ApacheBench. It is a Perl API to ab. It doesn't take a
> > > log per se, it simply sends sequences of HTTP requests and benchmarks the
> > > results. I'm sure you could very easily write a script to parse a log and then
> > > make a benchmarking run out of it.
> >
> > Yes, I considered ab and I did find HTTPD::Bench::ApacheBench, while
> > excellently
> > done and copiously documented, isn't quite what I need:
> >
> > 1) I want to spoof the IP addresses of the browsers (I just realized
> > that since I'm using mod_proxy_add_forward anyway, I can make the
> > requester script like a proxy; the rest is cookbook). I can't find
> > provision for that in the interface for HTTPD::Bench::ApacheBench.
>
> Yeah, that would require adding arbitrary HTTP headers to each benchmark
> request... that's currently on our to-do list (I think).
>
> > 2) Record the query parameters as well as the response's MD5 checksum
> > directly in a database table on the fly.
>
> This is all possible with ApacheBench. It wouldn't be stored in real-time (i.e.
> as the request is sent) but you set up the benchmarking runs, so you know all
> the query parameters (which are all either in the URI or the postdata for each
> request), and ApacheBench returns all the response data, which you can then pass
> thru an MD5 hash and store in the database.
>
> > 3) The interface is more suited to setting up, then executing a batch
> > run programmatically, rather than replaying a log.
>
> Right.. it was designed to be generally useful. To replay a log you simply need
> to set up a batch that exactly duplicates your log.
As I understand ApacheBench, to set up a really large (1M) run with say
200
or 300 URI's with ApacheBench distributed randomly across 400K unique IP
addresses, you just about would end up doing 1 run per access log entry,
which turns it into a really massive data structure, at which point a
file
starts looking like a better place to put all that.
Or, I could try forking off ApacheBench objects one by one, putting runs
into the next object to fork while the most recently forked object beats
on the server. Kind of a roundabout way of trading off complexity
against
RAM.
[snippage]
>
> > to me in that the last line in the execute method, "return $self->ab;" is
> > the only mention of the class method "ab" in the entire file. Obviously I
>
> That's because "ab" is the XS function that sends the HTTP requests and builds
> up a hash with all the response data and times. All the looping is done in C
> for speed. Take a look at ApacheBench.xs. (especially if you feel like adding
> the arbitrary HTTP request header functionality, hint hint :)
What would be nice from the self-documenting code point of view for a
newby like me would be a clue _in_the_code_itself_ that ApacheBench.xs
was the place to look for the definition of ab. That's how I would
expect a programming language to behave :), but that's something more
for the Perl 6 list.
> > have _much, much_ more to learn ... :)
>
> No, actually you pointed out some good feature additions that we should think
> about making to ApacheBench. Thanks.
>
You're welcome.
> -Adi
--Christopher
Christopher L. Everett
[EMAIL PROTECTED]
