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

bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com
Mon May 1 20:12:09 EDT 2006

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.


--- 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
+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 ... ;-)

More information about the mono-bugs mailing list