You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by co...@apache.org on 2012/04/02 14:53:50 UTC
svn commit: r1308330 -
/httpd/httpd/branches/2.4.x/docs/manual/programs/ab.xml
Author: covener
Date: Mon Apr 2 12:53:49 2012
New Revision: 1308330
URL: http://svn.apache.org/viewvc?rev=1308330&view=rev
Log:
Merge r1308327 from trunk:
remove the example output because <pre> and <note> cause fatal XSLT when
creating the manpage version of apxs. This seems to not run for some other
folks. (also, move new decsription stuff so it precedes bugs)
Modified:
httpd/httpd/branches/2.4.x/docs/manual/programs/ab.xml
Modified: httpd/httpd/branches/2.4.x/docs/manual/programs/ab.xml
URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/programs/ab.xml?rev=1308330&r1=1308329&r2=1308330&view=diff
==============================================================================
--- httpd/httpd/branches/2.4.x/docs/manual/programs/ab.xml (original)
+++ httpd/httpd/branches/2.4.x/docs/manual/programs/ab.xml Mon Apr 2 12:53:49 2012
@@ -205,57 +205,7 @@
</dl>
</section>
-<section id="bugs"><title>Bugs</title>
- <p>There are various statically declared buffers of fixed length. Combined
- with the lazy parsing of the command line arguments, the response headers
- from the server and other external inputs, this might bite you.</p>
-
- <p>It does not implement HTTP/1.x fully; only accepts some 'expected' forms
- of responses. The rather heavy use of <code>strstr(3)</code> shows up top
- in profile, which might indicate a performance problem; <em>i.e.</em>, you
- would measure the <code>ab</code> performance rather than the server's.</p>
-</section>
-
-<section id="output"><title>Example Output</title>
-
- <p>Sample output is provided here.</p>
- <note><pre>Server Software: Apache/2.2.17
-Server Hostname: testserver.com
-Server Port: 80
-
-Document Path: /index.html
-Document Length: 787 bytes
-
-Concurrency Level: 5
-Time taken for tests: 0.436 seconds
-Complete requests: 1000
-Failed requests: 0
-Write errors: 0
-Total transferred: 1026000 bytes
-HTML transferred: 787000 bytes
-Requests per second: 2292.26 [#/sec] (mean)
-Time per request: 2.181 [ms] (mean)
-Time per request: 0.436 [ms] (mean, across all concurrent requests)
-Transfer rate: 2296.74 [Kbytes/sec] received
-
-Connection Times (ms)
- min mean[+/-sd] median max
-Connect: 0 1 0.4 1 3
-Processing: 1 1 0.4 1 3
-Waiting: 0 1 0.5 1 2
-Total: 2 2 0.1 2 3
-
-Percentage of the requests served within a certain time (ms)
- 50% 2
- 66% 2
- 75% 2
- 80% 2
- 90% 2
- 95% 2
- 98% 2
- 99% 3
- 100% 3 (longest request)</pre></note>
-
+<section id="output"><title>Description of output</title>
<p>The output may vary depending on the command line parameters given.
Possible output with a brief explanation of each element is listed below.
</p>
@@ -341,4 +291,17 @@ Percentage of the requests served within
<code>totalread / 1024 / timetaken</code></dd>
</dl>
</section>
+
+<section id="bugs"><title>Bugs</title>
+ <p>There are various statically declared buffers of fixed length. Combined
+ with the lazy parsing of the command line arguments, the response headers
+ from the server and other external inputs, this might bite you.</p>
+
+ <p>It does not implement HTTP/1.x fully; only accepts some 'expected' forms
+ of responses. The rather heavy use of <code>strstr(3)</code> shows up top
+ in profile, which might indicate a performance problem; <em>i.e.</em>, you
+ would measure the <code>ab</code> performance rather than the server's.</p>
+</section>
+
+
</manualpage>