[Mono-bugs] [Bug 78075][Nor] Changed - Mono SSL stack performance/tuning issues

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by sebastien at ximian.com.

http://bugzilla.ximian.com/show_bug.cgi?id=78075

--- shadow/78075	2006-05-01 19:01:10.000000000 -0400
+++ shadow/78075.tmp.11276	2006-05-01 20:12:09.000000000 -0400
@@ -392,6 +392,33 @@
 
 mono client, SSL RC4/SHA1/128b = 37 secs net download (97 seconds less
 than AES/256!)
 
 there is, of course, a bit of variation between different runs,
 usually less than 2 seconds.
+
+------- Additional Comments From sebastien at ximian.com  2006-05-01 20:12 -------
+I'm not sure how you can compare (or interpret the results from) ZLM
+times versus wget times.
+
+To compare SSL performance you can either:
+
+* compare the times of an older ZLM with a newer one - but that
+wouldn't be very interesting to get cryptographic results;
+
+* compare the times of an older ZLM with wget, then compare the
+results with the newer ZLM. More interesting but still not enough
+crypto related wrt the bug summary;
+
+* use the attached mget source code and compare the SSL/TLS speed
+between Mono and wget. Both tools are doing the same and only thing:
+transfering data using from an URL. Once done, you can compare mget
+with ZLM to see how much time comes from ZLM itself and the Mono SSL
+stack.
+
+You can also use ethereal (on a smaller RPM) to see which cipher gets
+negotiated during the SSL/TLS handshake. That way you'll be sure if
+it's AES256 or (I really doubt) something else.
+
+Side note: we do not share the same definition of "order of magnitude"
+because in mine: 1 order of magnitude == 10x, 2 order of magnitude ==
+100x ... ;-)