httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@apache.org>
Subject Re: Contributions to Flood...
Date Tue, 10 Dec 2002 00:45:13 GMT
--On Monday, December 9, 2002 7:32 PM -0500 Donald Doane 
<ddoane@opendemand.com> 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:

http://httpd.apache.org/dev/patches.html

(Replace dev@httpd.apache.org with test-dev@httpd.apache.org.)

> 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?

> 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

Mime
View raw message