You are viewing a plain text version of this content. The canonical link for it is here.
Posted to test-dev@httpd.apache.org by Aaron Bannert <aa...@clove.org> on 2002/03/26 00:29:30 UTC
Re: cvs commit: httpd-test/flood/build apr_common.m4
Hmm..shouldn't we be using apr_common.m4 instead of checking it into
our repository? I've changed things in APR's version of this file
very recently, and I don't think we should be maintaining our own
copy.
-aaron
On Mon, Mar 25, 2002 at 10:58:20PM -0000, jerenkrantz@apache.org wrote:
> jerenkrantz 02/03/25 14:58:20
>
> Modified: flood CHANGES configure.in
> Added: flood/build apr_common.m4
> Log:
> - Fix up building of source apr and apr-util directly by using the
> m4 macros from APR for calling APR_SUBDIR_CONFIG.
> - Add config.nice support.
> - Fix typo when we can not find OpenSSL.
Newbie questions
Posted by Simon Bécot <si...@softeam.fr>.
Hi all
These may appear a silly questions but I'm newbie in load testing.
I'm looking for a tool for load testing an internet service. My question is:
does flood, or Perl Framework only work with Apache, or can it be used with
any http server?
Second question: Can theses tools be deployed on several machines? For
example if I want to load 200 client threads, I'd better put 4 client
machines with 50 threads, and 1 server that manages those 200 clients. If
I'm not doing that, I don't know if I'm testing the capacity of my client
machine to manage those 200 clients, because a test application can use as
much CPU as the server tested. The problem, is that the test application
should manage several machines to load simultaneously the threads, and to
merge the results of all the 200 clients from differents machines.
Thanks,
Simon.
Re: cvs commit: httpd-test/flood/build apr_common.m4
Posted by Justin Erenkrantz <je...@apache.org>.
On Tue, Mar 26, 2002 at 04:13:56PM -0800, Aaron Bannert wrote:
> On Tue, Mar 26, 2002 at 09:19:51AM -0800, Justin Erenkrantz wrote:
> > > If it's not installed as part of APR it should be. We shouldn't have it in
> > > our repository merely because we don't want to have to keep them in sync.
> >
> > It wouldn't make sense as part of the install as it is only needed
> > to build configure.
>
> I disagree. You can't have it both ways. If flood, an application that
> depends on an already-installed version of APR, requires some autoconf
> macros provided by APR then those macros must be installed by APR.
Uh, how can an installation of APR provide the macros? The paths
are hardcoded in flood's configure.in.
To be clear, we're talking about this line in configure.in:
dnl m4 Macros from APR
sinclude(build/apr_common.m4)
We have to have this file when we *generate* configure or autoconf
will die. We can't rely on installed versions of APR since we
don't know where these are and we have no way of telling autoconf
that. We also shouldn't have the user change that path to point at
their installed location of APR manually. Therefore, this file needs
to exist somewhere in *our* tree.
I think you're not understanding the problem here.
httpd will have this problem too. And, the only way I can see this
happening is to have its own copies of the macros. httpd-2.0
cheats by enforcing that apr must be in the source tree. -- justin
Re: cvs commit: httpd-test/flood/build apr_common.m4
Posted by Aaron Bannert <aa...@clove.org>.
On Tue, Mar 26, 2002 at 09:19:51AM -0800, Justin Erenkrantz wrote:
> > If it's not installed as part of APR it should be. We shouldn't have it in
> > our repository merely because we don't want to have to keep them in sync.
>
> It wouldn't make sense as part of the install as it is only needed
> to build configure.
I disagree. You can't have it both ways. If flood, an application that
depends on an already-installed version of APR, requires some autoconf
macros provided by APR then those macros must be installed by APR.
> It's not a matter of keeping them out of sync - I don't want to
> require that apr must be checked out underneath the flood tree
> (like what httpd-2.0 requires). I think that's a bad idea and
> I don't want to further that if we don't have to. I don't
> think it's the worst thing in the world if the versions are out
> of sync. -- justin
I don't want to require that either, which is why I'm saying we should
be picking it up from an APR install. HTTPD uses those macros, so as
soon as APR becomes a standalone library httpd will need a way to get
the apr_common.m4 file also.
-aaron
Re: cvs commit: httpd-test/flood/build apr_common.m4
Posted by Justin Erenkrantz <je...@apache.org>.
On Mon, Mar 25, 2002 at 06:37:41PM -0800, Aaron Bannert wrote:
> On Mon, Mar 25, 2002 at 03:34:27PM -0800, Justin Erenkrantz wrote:
> > I don't like relying on people having apr checked out in order to
> > build flood's configure - like what we require for httpd-2.0. I
> > don't want to go down that road. -- justin
>
> If it's not installed as part of APR it should be. We shouldn't have it in
> our repository merely because we don't want to have to keep them in sync.
It wouldn't make sense as part of the install as it is only needed
to build configure.
It's not a matter of keeping them out of sync - I don't want to
require that apr must be checked out underneath the flood tree
(like what httpd-2.0 requires). I think that's a bad idea and
I don't want to further that if we don't have to. I don't
think it's the worst thing in the world if the versions are out
of sync. -- justin
Re: cvs commit: httpd-test/flood/build apr_common.m4
Posted by Aaron Bannert <aa...@clove.org>.
On Mon, Mar 25, 2002 at 03:34:27PM -0800, Justin Erenkrantz wrote:
> I don't like relying on people having apr checked out in order to
> build flood's configure - like what we require for httpd-2.0. I
> don't want to go down that road. -- justin
If it's not installed as part of APR it should be. We shouldn't have it in
our repository merely because we don't want to have to keep them in sync.
-aaron
Re: cvs commit: httpd-test/flood/build apr_common.m4
Posted by Justin Erenkrantz <je...@apache.org>.
On Mon, Mar 25, 2002 at 03:29:30PM -0800, Aaron Bannert wrote:
> Hmm..shouldn't we be using apr_common.m4 instead of checking it into
> our repository? I've changed things in APR's version of this file
> very recently, and I don't think we should be maintaining our own
> copy.
How would you include it?
I don't like relying on people having apr checked out in order to
build flood's configure - like what we require for httpd-2.0. I
don't want to go down that road. -- justin