[Mono-bugs] [Bug 78075][Cri] Changed - Mono SSL stack
performance/tuning issues
bugzilla-daemon at bugzilla.ximian.com
bugzilla-daemon at bugzilla.ximian.com
Wed Apr 12 14:46: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.
http://bugzilla.ximian.com/show_bug.cgi?id=78075
--- shadow/78075 2006-04-11 06:04:56.000000000 -0400
+++ shadow/78075.tmp.26268 2006-04-12 14:46:41.000000000 -0400
@@ -1,14 +1,14 @@
Bug#: 78075
Product: Mono: Class Libraries
Version: 1.1
-OS:
+OS: unknown
OS Details:
Status: NEW
Resolution:
-Severity:
+Severity: Unknown
Priority: Critical
Component: Mono.Security
AssignedTo: miguel at ximian.com
ReportedBy: naresh at ximian.com
QAContact: mono-bugs at ximian.com
TargetMilestone: ---
@@ -22,6 +22,155 @@
Filing this to Miguel to discuss this further as this is a performance
based blocker for products such as OES (see also our corresponding bug
https://bugzilla.novell.com/show_bug.cgi?id=152909).
We'd like some advice on tuning the performance if that is possible and if
not what is planned to improve/fix this.
+
+------- Additional Comments From miguel at ximian.com 2006-04-12 14:46 -------
+I looked at the bugzilla pointed to, and asked Sebastien to look at
+this as well, and we do not believe that Mono is responsible for a
+slow-down of that magnitude.
+
+Mono is able to process 1 gigabyte in about 1.5 minutes downloading
+over https.
+
+Sebastien points out that there are a number of factors that could
+affect the performance. I will paste his message here.
+
+The bottom line is:
+
+* Your server might be picking up a more secure, but slower encryption
+method (Apache seems to be doing this). You would have to find out
+how to change this on Apache on the server side (if this is the source
+of the problem).
+
+* The code doing the transfer might be broken (see Sebastien's comment
+on cut-and-pasting code from Googling and how reading
+one-byte-at-a-time had a very significant impact compared to doing
+block reads).
+
+-------------------------------------------------------------
+
+* In SSL/TLS the server choose the cipher from a list of supported
+ciphers sent by the client;
+
+* The server used was IIS running on XP, so the timings were done with
+the RC4/128 cipher (confirmed with ethereal);
+
+* By default, Apache generally (version dependant) select AES/256 as
+the cipher (more secure but also slower);
+
+* The first test I did was by copy-pasting some code I googled. That
+was a very bad idea(tm). The code was using ReadByte from the stream
+to write into a file. I cancelled the 950Mb test after 20 minutes (it
+takes less than 2 minutes using the same code with a 16k buffer).
+
+* I didn't (yet) test with files bigger than 2Gb because I couldn't
+the compare results with wget (it doesn't like files bigger than 2Gb).
+I have a 3.5Gb file that I'll test this afternoon;
+
+
+And now the results...
+
+--------------------------------------------------------
+
+poupou at pollux:~> time mono mget.exe https://192.168.0.20/a.test
+GET https://192.168.0.20/a.test
+saving to: a.test
+completed in 00:00:00.8785160.
+
+
+real 0m1.345s
+user 0m0.735s
+sys 0m0.086s
+poupou at pollux:~> md5sum a.test
+8179df0372cdc4d34c67cbc76511bfa7 a.test
+
+
+
+poupou at pollux:~> time wget https://192.168.0.20/a.test
+--12:37:31-- https://192.168.0.20/a.test
+ => `a.test.1'
+Connecting to 192.168.0.20:443... connected.
+HTTP request sent, awaiting response... 200 OK
+Length: 2,816,200 [application/octet-stream]
+
+100%[=================================================================================================================>]
+2,816,200 8.61M/s
+
+12:37:31 (8.59 MB/s) - `a.test.1' saved [2816200/2816200]
+
+
+real 0m0.437s
+user 0m0.046s
+sys 0m0.039s
+poupou at pollux:~> md5sum a.test.1
+8179df0372cdc4d34c67cbc76511bfa7 a.test.1
+
+
+--------------------------------------------------------
+
+poupou at pollux:~> time mono mget.exe https://192.168.0.20/b.test
+GET https://192.168.0.20/b.test
+saving to: b.test
+completed in 00:00:05.5913260.
+
+
+real 0m6.181s
+user 0m4.200s
+sys 0m1.070s
+poupou at pollux:~> md5sum b.test
+9128d9b90aee3bb47750900fb6cbc7db b.test
+
+
+poupou at pollux:~> time wget https://192.168.0.20/b.test
+--12:33:15-- https://192.168.0.20/b.test
+ => `b.test.1'
+Connecting to 192.168.0.20:443... connected.
+HTTP request sent, awaiting response... 200 OK
+Length: 43,141,532 [application/octet-stream]
+
+100%[=================================================================================================================>]
+43,141,532 10.92M/s ETA 00:00
+
+12:33:19 (10.74 MB/s) - `b.test.1' saved [43141532/43141532]
+
+
+real 0m3.995s
+user 0m0.653s
+sys 0m0.590s
+poupou at pollux:~> md5sum b.test.1
+9128d9b90aee3bb47750900fb6cbc7db b.test.1
+
+--------------------------------------------------------
+
+poupou at pollux:~> time mono mget.exe https://192.168.0.20/c.test
+GET https://192.168.0.20/c.test
+saving to: c.test
+completed in 00:01:55.6666210.
+
+
+real 1m57.683s
+user 1m23.311s
+sys 0m24.658s
+
+
+poupou at pollux:~> time wget https://192.168.0.20/c.test
+--12:41:43-- https://192.168.0.20/c.test
+ => `c.test.1'
+Connecting to 192.168.0.20:443... connected.
+HTTP request sent, awaiting response... 200 OK
+Length: 974,141,440 [application/octet-stream]
+
+100%[=================================================================================================================>]
+974,141,440 10.89M/s ETA 00:00
+
+12:43:10 (10.63 MB/s) - `c.test.1' saved [974141440/974141440]
+
+
+real 1m27.702s
+user 0m14.855s
+sys 0m14.110s
+poupou at pollux:~> md5sum c.test.1
+f102ec1cd2ecc39cd292d1b0499f4e2a c.test.1
+
More information about the mono-bugs
mailing list