httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)" <>
Subject RE: [PATCH] ab with SSL support
Date Thu, 16 Aug 2001 17:08:45 GMT
This may be a very dumb question - but are you proposing to replace AB by
flood - for HTTP connections also - OR is it only for HTTPS connections ?.. 
I haven't yet looked into the httpd-test.. I'll certainly check out the
flood stuff..


-----Original Message-----
From: Aaron Bannert []
Sent: Thursday, August 16, 2001 9:24 AM
Subject: Re: [PATCH] ab with SSL support

On Thu, Aug 16, 2001 at 12:03:40AM -0700, Justin Erenkrantz wrote:
> On Wed, Aug 15, 2001 at 01:55:06PM -0700, MATHIHALLI,MADHUSUDAN
(HP-Cupertino,ex1) wrote:
> > Hi,
> > 	For those interested in having ApacheBench with SSL support, here's
> > the patch for ab.c.. I've done some tests (concurrency, keepalive, no.
> > requests) - there are still a lot of features which are yet to be
> > for SSL connections.. The patch is pretty simple - I just replace the
> > open/read/write/close function calls by the corresponding SSL
> > So, the basic functionality provided by AB for HTTP connections should
> > be available for HTTPS connections also.. 
> > 	The SSL support can be enabled by defining "USE_SSL" on the compile
> > line.. There's however, a small problem of performance penalty.. If AB
> > compiled with USE_SSL = ON, then there'll be atleast 4  "if (ssl == 1)"
> > statements executed for HTTP transactions.. I'm trying to get around it
- by
> > defining a separate path for HTTP & HTTPS transactions - any ideas are
> > welcome.. 
> A better solution may be flood rather than ab (see httpd-test CVS
> repository).  
> I'm sounding like a broken harp, but it'd be nice to get external 
> feedback on flood after the work we've put into it - we're using 
> it here internally, so we know it works, but I'd love to see what 
> people think about it.  Can we make it better (blah, blah, blah)?
> SSL works there (has all of the features you want to add to ab) and 
> you can do lots more with it.  That may come at *some* client-side 
> performance penalty, but flood is still much more lightweight than 
> the actual browsers people use.  So, the performance "penalty" is 
> probably negligable for meaningless benchmarks anyway.  -- justin

[warning: shameless plug]

The other thing about flood that was designed in from the start was the
various ways in which it scales. Right now flood can operate parallel
"user profiles" by assigning each to a thread, but we have plans for
this to scale to multiple processes and multiple machines, all controlled
by one flood process. We want this thing to be able to generate a huge
amount of traffic that resembles real-world traffic as closely as possible.

(Justin and I could use some help :)


View raw message