Mailing-List: contact test-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: test-dev@httpd.apache.org
Date: Fri, 24 Aug 2001 00:05:59 -0700
From: Aaron Bannert <aaron@clove.org>
To: test-dev@httpd.apache.org
Subject: Re: cvs commit: httpd-test/flood config.h.in configure.in flood.c
 flood_easy_reports.c flood_farm.c flood_net.c flood_net_ssl.c
 flood_report_relative_times.c
Message-ID: <20010824000559.C7084@clove.org>
References: <20010824042639.25011.qmail@icarus.apache.org>
 <20010823223550.Z17570@ebuilt.com> <20010823224757.H1714@clove.org>
 <20010823225435.C17570@ebuilt.com> <20010823231316.A7084@clove.org>
 <20010823232639.F17570@ebuilt.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010823232639.F17570@ebuilt.com>;
 from jerenkrantz@ebuilt.com on Thu, Aug 23, 2001 at 11:26:39PM -0700

On Thu, Aug 23, 2001 at 11:26:39PM -0700, Justin Erenkrantz wrote:
> On Thu, Aug 23, 2001 at 11:13:16PM -0700, Aaron Bannert wrote:
> > I thought mpmt was what we were striving for all along for platforms that
> > could support it. *BSD is the only platform we're really worried about
> > WRT threads, no?
> 
> It's the most glaring omission.  =)
> 
> > as much as possible". If you think we can emulate the typical 4-threaded
> > GUI browser by treating threads and processes the same, then I am totally
> > cool with that.
> 
> I think that is our best option at the farm level.  On platforms without
> threads, this is as close as we can get it.  
> 
> I think the key thing with the farm is that the count variable is 
> intended to be run in parallel not serial (unlike the count for a
> urllist which is implicitly serial).

Unfortunately that is not the case. A urllist is simply a list of
urls, it has no implicit ideas of being serial or parallel. We have
only implemented a roundrobin-style profile, which happens to use
a urllist in a serial manner, but there is no reason the same
urllist couldn't be used by a hundred farmers all in parallel
and in some bizarre non-linear manner (like random-weighted, for
example).


>                                       If we allow a farm to also
> be run in serial, then a test that can simulate 10 users by creating 
> 10 threads on platform X, but simulates 1 user doing the same
> thing 10x as long on platform Y isn't good.  So, yes, I think a farm 
> must be run in parallel.  =-)  If that's not in the docs, then too 
> bad.

You're missing my point. Although it matters to me that we have the
ability to run multiple farmers in parallel, it also matters to me that
we define these things beforehand. We discussed all of this before we
started coding and we decided that it would be 2-level, to basicly do an
MPMT model.  The patch you commited implicitly changes our definitions of
"collective" and "farm", but you seem reluctant to keep the design docs
in sync, or to acknowledge that this may limit our ability to accurately
represent some real-world scenarios. Like I said, I'd rather have the
flexibility to mix and match threads and processes, instead of making
it transparent to the user how the test was made parallel.

Maybe a better model would be simple 2-layer where each layer can
be implemented using threads or processes to achieve parallel processing
of the next level, only that the top level prefers forks and the bottom
layer prefers threads. Some creative coding could save us some code
duplication and it would satisfy both of the goals we are trying to
achieve here.


> FWIW, I'm going to be spending some time on the flood site/docs 
> tomorrow and over the weekend.  Roy's added the subproject members
> (you and jsachs) to httpd-site, so you should be able to commit
> there now too.  -- justin

Cool, that will be useful.

-aaron