httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cove...@apache.org
Subject svn commit: r1308330 - /httpd/httpd/branches/2.4.x/docs/manual/programs/ab.xml
Date Mon, 02 Apr 2012 12:53:50 GMT
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>



Mime
View raw message