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

bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com
Tue May 2 18:29:28 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-02 16:36:42.000000000 -0400
+++ shadow/78075.tmp.18850	2006-05-02 18:29:28.000000000 -0400
@@ -467,6 +467,71 @@
 ------- Additional Comments From james at ximian.com  2006-05-02 16:36 -------
 ZMD does virtually the same thing as mget.cs -- it reads a 8192 bytes
 on each read.
+------- Additional Comments From sebastien at ximian.com  2006-05-02 18:29 -------
+> I use openssl in client mode to check what cypher is being used, 
+> and did so for all the results posted - when I say one cypher was 
+> used, it was.
+Hey, I totally believe you, but you also said:
+> Default cypher is presumed to be "apache-standard" AES/256.
+and I assumed you weren't 100% sure about the AES/256 being the
+negotiated cipher. Ethereal was an easy way to find out without any
+change to the client or server.
+> Sebastien, can you comment on the why I would not be able to
+> compare download via rug/zlm vs wget ?
+You can compare, but the results just doesn't mean much. ZLM itself
+should be taking time (doing the transfer and/or other stuff, like
+initialization, logging...), requiring extra memory, extra JIT time...
+Substracting the install time from the total time does help - but it
+doesn't consider all the other stuff ZLM possibly does (directly or
+indirectly), so you're comparing SSL(mono)+extra(ZLM) with SSL(wget).
+By comparing mget/wget you compare the real SSL speed - which is the
+real issue: SSL(mono) versus SSL(wget). That won't make AES faster,
+but it will show more accurate results. Anyway feel free to try it (as
+I can't) and you'll see if the extra(ZLM) time exists or not.
+You can also try to vary the size of the downloaded RPM as the
+negotiation is very CPU intensive (and has no relation with the
+download size).
+Also, if it fit a real-life scenario for ZMD, you can try to download
+multiple RPM without re-staring the ZMD process (as this will require,
+under most circumstances, only a single handshake).
+> Go figure, I also thought the same. And 7 seconds, 37 seconds, 
+> 2m7sec (127 seconds) are *indeed* in three different orders,
+> the powers of ten 0, 1 and 2.
+yes and that exact statement would also be true if wget took 1 second
+and Mono took 999 seconds ;-) but you're free to find that a fair
+Personally I prefer using your numbers (even if they do not compare
+mget with wget)...
+37 / 7 = 5.3x, which is slow (if not quite one order of magnitude, 10x)
+127 / 7 = 18.14x, which is bad (if not even close to two order of
+magnitude, 100x)
+> Under the same configuration, wget takes 9 seconds.
+even if I'm not totally sure if it's 7 or 9 seconds I should be using
+to compare with 127s (127 / 9 = 14.11x).
+So my point isn't that the Mono crypto algorithms are fast. They are
+managed implementations, which inherits a lot of advantages but (even
+if they can get better) will *never* compare, performance wise, to
+hand-optimized assembly implementations as used in openssl, gnutls...
+In fact using a well known managed AES implementation (from a Mono
+competitor in the Windows world) would still be much slower than wget
+(sorry the competitor's EULA prohibits publishing benchmarks).

More information about the mono-bugs mailing list