Re: Contributions to Flood...

[Donald Doane <dd...@opendemand.com>]

>
>
>>
>
> Cool!  We'd appreciate any assistance you can offer!  =) 


That's great to hear!

>
>
> The first thing to know is that all coordination happens here on this 
> mailing list (test-dev@httpd.apache.org).  Please subscribe to the 
> list - I had to moderate your post through since you were not subscribed. 

I am now officially subscribed:-)

>
>
> So, we're not going to be doing anything that isn't talked about here 
> first.  If you are interested in contributing, I'd recommend posting 
> about what you'd like to see from flood and how you'd like to see it 
> happen on this list.  If you have code changes or bug fixes, post them 
> on this list and we will do our best to integrate them. 

We have already begun implementing several new features within Flood and 
making some minor bug fixes. From a high-level, we have 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.

> Right now, the state of flood is that the two original authors (myself 
> and Aaron Bannert) are happy with it - it does what we want. Another 
> committer (Jacek Prucia) has some additional ideas of where flood 
> should go (but he's been pressed for time to contribute lately). 

Would love to hear them.

>
>
> In short, my role right now is to try to ensure that flood can do what 
> other people want it to do.  About the only thing on the horizon for 
> me with Flood is to integrate Serf (a new HTTP client library) with 
> Flood.  But, that's a little while away - I have lots of other things 
> to worry about first.  =) 

Could you elaborate on the advantages of implementing Serf over the 
current HTTP client?

>
>
> Good luck and welcome!  -- justin
>
Thanks! We are looking forward to contributing to the project.

RegEx Support in Flood...

[Donald Doane <dd...@opendemand.com>]

I just recently did a build of Flood on Linux and am having trouble 
getting it to pick up "libpcre" and "libpcreposix". As a result I 
believe the responsetemplate matching isn't working; 
"flood_round_robin::regexec()" keeps returning a "REG_ASSERT".

Does anyone know how to get Flood to build with the pcre package?

Thank you for your help in advance.

:-Don

Re: Contributions to Flood...

[Donald Doane <dd...@opendemand.com>]

> --On Monday, December 9, 2002 7:32 PM -0500 Donald Doane 
> <dd...@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!) 


Understood.

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


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
>
Okay.

Re: Contributions to Flood...

[Justin Erenkrantz <je...@apache.org>]

--On Monday, December 9, 2002 7:32 PM -0500 Donald Doane 
<dd...@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