bagder: curl-www/libcurl/hiper _schedule.html,1.15,1.16

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

Modified Files:
	_schedule.html 
Log Message:
hopes for the new API


Index: _schedule.html
===================================================================
RCS file: /cvsroot/curl/curl-www/libcurl/hiper/_schedule.html,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -d -r1.15 -r1.16
--- _schedule.html	9 Dec 2005 10:39:34 -0000	1.15
+++ _schedule.html	9 Dec 2005 11:18:42 -0000	1.16
@@ -72,6 +72,27 @@
 <p>
  Each time above is in microseconds and is the average time of 5 or 6 test runs.
 
+<p>
+ What do I hope for in new "socket" extension of the multi API, in pure
+ numbers in comparison to graph above using a test that is identical "in
+ spirit"? (using curl_multi_socket() instead of curl_multi_perform())
+<p>
+<ol>
+
+<li> Time spent in curl_multi_socket() should be (more or less) fixed no
+ matter how many idle connections that are used. I sincerely hope that means
+ less than 10 microseconds in this test setup.
+
+<li> The select() benchmark graph below suggests that libevent is pretty much
+ fixed at 50 microseconds (although I don't know what test box was used in
+ their testing, we can compare the select()-times from my tests and see that
+ they are at least resonably close).
+
+<li> Summing up, the collected ~40 ms spent at 9000 connections could possibly
+ be lowered to something around 60 us!
+
+</ol>
+
 STOP
 
 MARKDATE(Dec 7 2005) Different test/measure approach: