On Mon, 11 Aug 2003 16:26:34 -0700 Justin Erenkrantz <[EMAIL PROTECTED]> wrote:
> --On Sunday, August 10, 2003 23:24:04 +0200 Jacek Prucia > <[EMAIL PROTECTED]> wrote: > > > This probably belongs in contrib/patches. It is a quick'n'dirty hack > > I did few days ago, to simulate applet making network connection. > > Basically it allows for something like this: > > > > <url > > responsescript="/path/to/script.py">http://www.example.com/</url> > > I wouldn't see an issue just placing this in the main code rather than > as a separate patch. Just place in the documentation that the use of > this attribute may distort the timings. OK. Will do after the rewrite (see Aaron post). > Hmm. If we did this *after* the close is done, would we still have a > problem with the timing? I don't think we would, but I could be > wrong. (Perhaps we're freeing the response buffer at that time. I > forget.) How about a keepalives? We keep socket open until "Connection: Close" header arrives, or we run out of urls (IIRC). However, this not the only place, that can bork timings. We will have more of them in future, as flood can be used in two types of tests -- performance and regression (with capacity planning being a mixture of the two). The first one tries to produce as many requests as it can, and pays more attenion to timings. The other is basically only interested in response and it's content. So as development goes on with regression-type features (my personal puppy), we will have more time distortions. There are two ways to reduce that. The first one is to have two modes of operation with magic attribute: dynamic. For example, variable expansion in urllist would only occur, if that url list would have attribute dynamic set to "yes". Flood could ignore few other attributes (including responsescript) when in non-dynamic mode. This would also allow us to clean url element a bit, as it is bloated with attributes. The second way, is to have precise timing of interesting operations, rather that time check at milestone flood phases (what we have right now). Something like that (pseudocode): time_start = time(); perform_operation(); time_end = time(); exact_time = time_end - time_start; As time operations seems to be expensive (IIRC), we might use such precise timing where such precision is really needed (like response time of web server) and standard measuring else. However, I'm not so sure if this is the right way, as this (probably, not sure) introduces some issues in how we report timings. > Watch out for C++-style comments (i.e. //) - that's not supported by a > bunch of C compilers. ;-) -- justin No to mention violating ASF style guide. Thank's for catching this one out. I do a lot of Javascript recently (Flood URL Bag for Mozilla), and this is how that little thing sneak in :) regards, Jacek Prucia
