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 [EMAIL PROTECTED])
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
