[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 23:08:41 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 miguel at ximian.com.


--- shadow/78075	2006-05-02 18:29:28.000000000 -0400
+++ shadow/78075.tmp.26998	2006-05-02 23:08:41.000000000 -0400
@@ -532,6 +532,29 @@
 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).
+------- Additional Comments From miguel at ximian.com  2006-05-02 23:08 -------
+Am not sure there is much that we can do here at this point.  If the
+setup does not allow for the fast https transfers as described
+originally due to the encryption used let me recommend that folks use
+System.Diagnostics.Process.Start ("wget http://url").
+The constraints on us are:
+* It is too late for us to make changes to the crypto stack for CODE
+10 (the crypto deadline was sometime in January).
+* There is no way we can complete and then backport any of the JIT
+optimizations that might get 10-15% of improvement in the best case in
+time for you to ship.
+* There is no way we can bind OpenSSL and use it in our stack in the
+If the ZLM server can not downgrade the cryptographic algorithm on the
+server, then my suggestion is to use wget as described before.
+Btw, am confused about wget and libssl, because I could swear those
+licenses were incompatible.

More information about the mono-bugs mailing list