You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Martin Kraemer <Ma...@Fujitsu-Siemens.com> on 2001/08/23 15:53:14 UTC
Re: Flood
>
> You can devise a user profile that flood will execute (i.e. a sequence
> of URLs - potentially dynamic) rather than a single static URL as ab
> lets you do. -- justin
How does it compare to httperf?
Martin
--
<Ma...@Fujitsu-Siemens.com> | Fujitsu Siemens
<ma...@apache.org> | 81730 Munich, Germany
Re: Flood
Posted by Manoj Kasichainula <ma...@io.com>.
On Thu, Aug 23, 2001 at 09:08:43AM -0700, Justin Erenkrantz wrote:
> The question is where should this go. Should we have
> test.httpd.apache.org? Or should I just slap info on httpd.apache.org?
The convention I've seen in Jakartaland is to use
http://jakarta.apache.org/module/
Re: Flood
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Thu, Aug 23, 2001 at 09:01:16AM -0700, Ian Holsman wrote:
> Is it worth putting up a page somewhere on httpd.apache.org mentioning
> the test stuff (with links to join etc, and a description of what is in
> there ?)
Probably. =-)
The question is where should this go. Should we have
test.httpd.apache.org? Or should I just slap info on httpd.apache.org?
But that'd mean that anyone wanting to modify the test pages (i.e. Aaron
or one of the other Covalent people working on the perl section) would
need httpd-site access.
Thoughts? -- justin
Re: Flood
Posted by Ian Holsman <ia...@cnet.com>.
Is it worth putting up a page somewhere on httpd.apache.org mentioning
the test stuff (with links to join etc, and a description of what is in
there ?)
On Thu, 2001-08-23 at 08:56, Justin Erenkrantz wrote:
> On Thu, Aug 23, 2001 at 03:53:14PM +0200, Martin Kraemer wrote:
> > >
> > > You can devise a user profile that flood will execute (i.e. a sequence
> > > of URLs - potentially dynamic) rather than a single static URL as ab
> > > lets you do. -- justin
> >
> > How does it compare to httperf?
>
> Well, Aaron, Roy, and myself did look at httperf before we started
> development on flood. However, you don't have to write C modules
> to extend flood's "workload generators" (to use httperf's jargon).
> You can write C modules to extend how flood operates, but that's not
> required to specify which URLs you wish to hit.
>
> Basically, we have the ability to mimic a complete user profile in a XML
> format. This snippet is based off of examples/round-robin-example.xml
> in httpd-test (slightly cleaned up):
>
> <urllist>
> <name>Apachelabs.org search profile</name>
> <description>Search for httpd-2.0 commit access and get the first two messages in the thread</description>
> <url method="POST" payload="method=and&format=builtin-long&sort=score&config=htdig&restrict=&exclude=&words=httpd-2.0+commit+access"
> responsetemplate="<a href="([^"]*)">" responsename="id">http://www.apachelabs.org/cgi-bin/htsearch</url>
> <url requesttemplate="${id}" responsetemplate="<A HREF="([^"]*)">Next</A>" responsename="next" />
> <url requesttemplate="http://www.apachelabs.org${next}" />
> </urllist>
>
> The first URL does a POST as a htdig query searching for "httpd-2.0
> commit access" on apachelabs.org. Notice the HTML escaping present -
> since we are using XML format, we must escape everything - that kind of
> sucks, but without writing our own pseudo-XML parser (we use APR-util's
> XML API) we don't have much of a choice here. =)
>
> When the search returns, we look for the first occurrance of "<a
> href="http://www.apachelabs.org/foo/bar.html"> (regexp matching) and
> place http://www.apachelabs.org/foo/bar.html in the variable id.
>
> The next URL simply uses that variable directly to be the next URL to
> hit. Then, once we retrieve that URL, we look for
> "<A HREF="/spaz/bar.html">Next</A> and store /spaz/bar.html into the
> variable next.
>
> We then hit the final URL in our sequence with that message.
>
> See if you can do this in three lines with httperf. =)
>
> Current features that httperf supports that we don't:
> Chunked encoding (on our short list when we get around to it)
> Log-file replay (this is conceptually easy except for POST payloads)
> As much network information detail
>
> Flood's output is pretty raw at this point. We output it so that it is
> easy to run your own statistical analysis/summary on the results. So,
> we expect you to write awk/perl scripts - we have a bunch that we use
> internally to generate result summaries. I may commit modified versions
> of some of them when time permits. (We also run flood in combination
> with sar and snoop at times to generate more OS specific data...)
>
> Features we support that httperf doesn't:
> SSL
> Better delay handling (per URL)
> slightly-easier configuration
> Threading
>
> Threading is a mixed bag performance-wise as poll() based is slightly
> better performance wise, but remember that we aren't going for
> meaningless benchmarks *choke* ab *choke*, but "real-world" numbers -
> so a thread/user makes a lot of sense implementation-wise.
>
> Like httperf, we'd like to have a "daemon-mode" where we can spread out
> flood sessions across multiple machines and have all of the reports go
> to one central place.
>
> Anyway, we're using flood internally at eBuilt to performance test
> one of our client's websites (the XML gets quite hairy as the site is
> very complex). So, we're trying to first build in the features
> that we need and then focus on other things later as time permits.
> We've found a number of bottlenecks and problematic pages under load
> on that site. We're able to tell them which pages are worse under
> load, etc, etc. So, it is scratching our itch.
>
> Ideally, other people will find this tool of value and use it. And,
> if they find problems (or need new features), they can submit patches
> (or commit themselves). We'd definitely welcome the help. HTH.
> -- justin
--
Ian Holsman IanH@cnet.com
Performance Measurement & Analysis
CNET Networks - (415) 364-8608
Re: Flood
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Thu, Aug 23, 2001 at 03:53:14PM +0200, Martin Kraemer wrote:
> >
> > You can devise a user profile that flood will execute (i.e. a sequence
> > of URLs - potentially dynamic) rather than a single static URL as ab
> > lets you do. -- justin
>
> How does it compare to httperf?
Well, Aaron, Roy, and myself did look at httperf before we started
development on flood. However, you don't have to write C modules
to extend flood's "workload generators" (to use httperf's jargon).
You can write C modules to extend how flood operates, but that's not
required to specify which URLs you wish to hit.
Basically, we have the ability to mimic a complete user profile in a XML
format. This snippet is based off of examples/round-robin-example.xml
in httpd-test (slightly cleaned up):
<urllist>
<name>Apachelabs.org search profile</name>
<description>Search for httpd-2.0 commit access and get the first two messages in the thread</description>
<url method="POST" payload="method=and&format=builtin-long&sort=score&config=htdig&restrict=&exclude=&words=httpd-2.0+commit+access"
responsetemplate="<a href="([^"]*)">" responsename="id">http://www.apachelabs.org/cgi-bin/htsearch</url>
<url requesttemplate="${id}" responsetemplate="<A HREF="([^"]*)">Next</A>" responsename="next" />
<url requesttemplate="http://www.apachelabs.org${next}" />
</urllist>
The first URL does a POST as a htdig query searching for "httpd-2.0
commit access" on apachelabs.org. Notice the HTML escaping present -
since we are using XML format, we must escape everything - that kind of
sucks, but without writing our own pseudo-XML parser (we use APR-util's
XML API) we don't have much of a choice here. =)
When the search returns, we look for the first occurrance of "<a
href="http://www.apachelabs.org/foo/bar.html"> (regexp matching) and
place http://www.apachelabs.org/foo/bar.html in the variable id.
The next URL simply uses that variable directly to be the next URL to
hit. Then, once we retrieve that URL, we look for
"<A HREF="/spaz/bar.html">Next</A> and store /spaz/bar.html into the
variable next.
We then hit the final URL in our sequence with that message.
See if you can do this in three lines with httperf. =)
Current features that httperf supports that we don't:
Chunked encoding (on our short list when we get around to it)
Log-file replay (this is conceptually easy except for POST payloads)
As much network information detail
Flood's output is pretty raw at this point. We output it so that it is
easy to run your own statistical analysis/summary on the results. So,
we expect you to write awk/perl scripts - we have a bunch that we use
internally to generate result summaries. I may commit modified versions
of some of them when time permits. (We also run flood in combination
with sar and snoop at times to generate more OS specific data...)
Features we support that httperf doesn't:
SSL
Better delay handling (per URL)
slightly-easier configuration
Threading
Threading is a mixed bag performance-wise as poll() based is slightly
better performance wise, but remember that we aren't going for
meaningless benchmarks *choke* ab *choke*, but "real-world" numbers -
so a thread/user makes a lot of sense implementation-wise.
Like httperf, we'd like to have a "daemon-mode" where we can spread out
flood sessions across multiple machines and have all of the reports go
to one central place.
Anyway, we're using flood internally at eBuilt to performance test
one of our client's websites (the XML gets quite hairy as the site is
very complex). So, we're trying to first build in the features
that we need and then focus on other things later as time permits.
We've found a number of bottlenecks and problematic pages under load
on that site. We're able to tell them which pages are worse under
load, etc, etc. So, it is scratching our itch.
Ideally, other people will find this tool of value and use it. And,
if they find problems (or need new features), they can submit patches
(or commit themselves). We'd definitely welcome the help. HTH.
-- justin