httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Doane <>
Subject Re: Contributions to Flood...
Date Tue, 10 Dec 2002 04:13:49 GMT
> --On Monday, December 9, 2002 7:32 PM -0500 Donald Doane 
> <> wrote:
>> We have already begun implementing several new features within
>> Flood and making some minor bug fixes. From a high-level, we have
> By all means, please feel free to contribute them back to us!  No 
> matter how large or small the patches are, we'll look at them.  Yet, 
> to ease our review, it would be best if the patches are small enough 
> to easily review.  (No mega patches, please!) 


> The following URL describes the process for submitting patches:
> (Replace with
>> begun work on items listed in the Flood design spec, including
>> expanding timing metrics and the notion of a virtual user as it
>> relates to a collection of URLs (i.e. profile) as well as
>> implementing error detection and complex response validation. We've
>> also expanding the reporting to use and XML schema. Right now, we
>> are developing on both Windows and LINUX with plans to do testing
>> on Solaris and AIX by January.
> Cool deal - as I said, I look forward to seeing patches.  =)
> I'd be curious to see what you guys think of our framework.  Has it 
> proven to be a good idea, or are there some places where we could 
> improve? 

The framework has proven to be very useful in that it allows us to 
easily extend's Flood existing functionality.

>> Could you elaborate on the advantages of implementing Serf over the
>> current HTTP client?
> Currently, there are some things that are hard to do in the current 
> HTTP client code in flood.  For example, it isn't possible to easily 
> add 'deflate' compression support to flood.  Yet, serf already has the 
> ability to do that for us (in addition to SSL, chunking, etc.). The 
> HTTP client code in flood should work, but it's kind of at the 
> breaking point.  So, I think to make the client code more extensible, 
> we'd need to take another strategy.  Yet, in all of our tests, we 
> never found flood to be the bottleneck.  So, it is fairly efficient as 
> is.  It's just not very extensible.  -- justin

View raw message