bagder: curl-www/libcurl/hiper _schedule.html, 1.14, 1.15 perf-20051209.png, NONE, 1.1 perf-20051209t.png, NONE, 1.1

Update of /cvsroot/curl/curl-www/libcurl/hiper
In directory labb:/tmp/cvs-serv18691

Modified Files:
	_schedule.html 
Added Files:
	perf-20051209.png perf-20051209t.png 
Log Message:
new info, new graph


--- NEW FILE: perf-20051209t.png ---
(This appears to be a binary file; contents omitted.)

Index: _schedule.html
===================================================================
RCS file: /cvsroot/curl/curl-www/libcurl/hiper/_schedule.html,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -d -r1.14 -r1.15
--- _schedule.html	7 Dec 2005 15:42:34 -0000	1.14
+++ _schedule.html	9 Dec 2005 10:39:34 -0000	1.15
@@ -32,6 +32,48 @@
 
 <table class="news">
 
+MARKDATE(Dec 9 2005) I consider this round of tests to complete my first
+ investigation and measure phase in which I've carefully studied how an
+ applicaton performs with the existing API and the accompanying "enforced" use
+ of select().
+
+<p>
+ I worked around the 1024 connection limits for both
+ server and client side. I built the test program and ran it to use a single
+ active connection and N number of idle ones (idle meaning the server never
+ repsonds with any data, it just keeps the connection alive).
+<p>
+ The results were pretty much as I had imagined, and I'm pleased with the test
+ setup and the stable and repeatable test numbers. Due to the amount of RAM in
+ my test box, and the amount of memory required for each single connection in
+ both the client and server (since they were running on the same box), I
+ stopped testing at 9000 simultaneous connections since doing more would've
+ forced use of swap and killed all reliable results.
+<p>
+ I ran the test client with 1001, 2001, 3001, 5001 and 9001 connections and
+ measured how long select() and curl_multi_perform() would take in average,
+ over a period of 20 seconds. Each read call in libcurl would only read one
+ single byte, so thus we are sure that the active connection will be
+ "readable" in the select() sense during the entire test. It also ensured that
+ there would be no significant time spent in the read() call itself. The
+ read() overhead is thus also constant in all the tests.
+<p>
+ <a href="perf-20051209.png"><img src="perf-20051209t.png" border="0"></a>
+<p>
+ The exact numbers of the graph are:
+<pre>
+Connections  multi_perform  select
+1001         3504           951
+2001         7606           1988
+3001         11045          2715
+5001         16406          4024
+9001         32147          8030
+</pre>
+<p>
+ Each time above is in microseconds and is the average time of 5 or 6 test runs.
+
+STOP
+
 MARKDATE(Dec 7 2005) Different test/measure approach:
 
 <p> I now have a local HTTP server that can serve two modes: idle and

--- NEW FILE: perf-20051209.png ---
(This appears to be a binary file; contents omitted.)