Apparent slow websocket performance in chrome when running in wss secure mode and connecting to localhost

[rang...@googlemail.com]

Google Chrome 35.0.1916.153 (Official Build 274914) m

OS: Windows7 64bit

I seem to be experiencing issues that suggest wss secure websockets are much slower on Chrome than IE and Firefox. I've trawled around but cannot find any real info to confirm others see this behaviour. It seems particularly noticeable when using SSL.

In summary: I'm prototyping using a localhost C++ websocket server to send data to a webpage that is opened on the same machine. Some of this data will be binary image png frames.I cannot really stream video and use a video tag,as the latency/lag has to be minimum.

This has to be the secure wss version of websockets. Thus I'm currently using a self signed certificate that has been added to the Trusted Root Certification Authorities Certificate Store. 

One of the potentially limiting factors is how much data throughput the websocket connection will give. Currently just for prototyping, I'm using mongoose as the server. The server doesn't seem to be the limiting factor, it seems to be Chrome wss websocket handling.

Tests on my high'ish spec dev machine just send data over the websocket. Currently I'm not trying to do anything with the actual data that is passed. Client sends a wss client->server string saying "pull". Server replies with wss server-client 1 Megabyte binary blob. Client replies with wss client-server string saying "pull". Server replies with wss server-client 1 Megabyte binary blob. ..and so on ...

Here are the number of 1 Megabyte binary frames I get per second, for both secure and unsecured websockets:

IE (v10) wss:120 ws:221

Firefox (v28) wss:65 ws:170

Chrome (v35) wss:17 ws:93

You can see that chrome wss performance seems very slow in comparison to the others. I've tried this on 3 computers with similar results. I've tried different blob sizes for 0.1 Megabyte to 100 Megabyte and this makes no real difference to actual data rate throughput. I've tried disabling Nagle's algorith. I've tried 127.0.0.1 instead of localhost.

My instinct is that it isn't the server, but I may be wrong. Has anyone any ideas on something that I may be missing, or how to progress? Can anyone confirm that this slow chrome wss performance is a known issue?

thanks in advance for any responses ...

Matt

..............................

Additional info #1:

I enabled '#enable-websocket-experimental-implementation', but it seemed to make no difference. I also tried the latest chrome canary build but this also seemed to make no difference.

..............................

Additional info #2:

More results testing using 2 sockets per client instead of 1, each on different websocket sub protocol. As above in cycles per second, with a 1 Megabyte binary frame.

IE(v10) : wss:120 ws:221 wss[2 websockets]:176

Firefox(v28) : wss:65 ws:170 wss[2 websockets]:59

Chrome(v35) wss:17 ws:93 wss[2 websockets]:18

IE seems to speed up significantly using 2 websockets. Firefox and Chrome don't.

..............................

[Chris Bentzel]

--
--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-discuss

[Takeshi Yoshino]

Thanks for the report.

We conducted some benchmark tests, and it seems the difference of cipher suite choice between Firefox and Chrome is affecting the performance.

We're using pywebsocket for benchmarking. From my Windows 7 machine, taking to a pywebsocket standalone server, Chrome canary uses AES 128 GCM + SHA-256 while Firefox Aurora uses AES 128 CBC + SHA-1. And, yes, Chrome was slower. But the difference is not so big as your report. It was ~2 times. If I enforce them to use the same suite, the results become very close. Could you please take a look at cipher suite choice by clicking the lock icon?

[Takeshi Yoshino]

+sleevi, agl for comments by experts

[Takeshi Yoshino]

Here's the result of cipher suite comparison.

Note

- Windows results are taken by running the browser and server on different machines while Linux results are taken by running them on the same machine.

- Windows and Linux machine have different spec

For Linux-samehost test AES128-GCM-SHA256 performs better than AES128-SHA

For Windows-remotehost test AES128-SHA performs better than AES128-GCM-SHA256

AES128-SHA

mozilla/5.0 (windows nt 6.1; win64; x64) applewebkit/537.36 (khtml, like gecko) chrome/38.0.2067.2 safari/537.36

Receive benchmark

Message size in KiB, Time/message in ms, Speed in kB/s

Connect wss://araiguma3.tok:30443/benchmark_helper

Opened

10 0.2668 38380.81

50 1.113 46001.797

100 2.228 45960.503

500 11.08 46209.386

1000 22.9 44716.157

5000 131.65 38890.999

10000 256.3 39953.18

50000 1290 39689.922

100000 2728 37536.657

Finished

mozilla/5.0 (x11; linux x86_64) applewebkit/537.36 (khtml, like gecko) chrome/38.0.2068.0 safari/537.36

Receive benchmark

Message size in KiB, Time/message in ms, Speed in kB/s

Connect wss://araiguma3.tok:30443/benchmark_helper

Opened

10 0.1281 79937.549

50 1.1745 43593.018

100 2.309 44348.203

500 11.215 45653.143

1000 24.58 41659.886

5000 149.35 34281.888

10000 282.3 36273.468

50000 1446.5 35395.783

100000 3083 33214.402

Finished

AES128-GCM-SHA256

mozilla/5.0 (windows nt 6.1; win64; x64) applewebkit/537.36 (khtml, like gecko) chrome/38.0.2067.2 safari/537.36

Receive benchmark

Message size in KiB, Time/message in ms, Speed in kB/s

Connect wss://araiguma3.tok:30443/benchmark_helper

Opened

10 0.498 20562.249

50 2.137 23958.821

100 4.189 24444.975

500 21.005 24375.149

1000 42.4 24150.943

5000 219.55 23320.428

10000 448.9 22811.317

50000 2419.5 21161.397

100000 4644 22049.957

Finished

mozilla/5.0 (x11; linux x86_64) applewebkit/537.36 (khtml, like gecko) chrome/38.0.2068.0 safari/537.36

Receive benchmark

Message size in KiB, Time/message in ms, Speed in kB/s

Connect wss://araiguma3.tok:30443/benchmark_helper

Opened

10 0.1319 77634.572

50 0.64 80000

100 1.389 73722.102

500 7.455 68678.739

1000 17.14 59743.291

5000 93.2 54935.622

10000 191.1 53584.511

50000 988.5 51795.65

100000 2144 47761.194

Finished

RC4-SHA

mozilla/5.0 (windows nt 6.1; win64; x64) applewebkit/537.36 (khtml, like gecko) chrome/38.0.2067.2 safari/537.36

Receive benchmark

Message size in KiB, Time/message in ms, Speed in kB/s

Connect wss://araiguma3.tok:30443/benchmark_helper

Opened

10 0.2238 45755.139

50 0.7375 69423.729

100 1.499 68312.208

500 8.37 61170.848

1000 16.92 60520.095

5000 83.55 61280.67

10000 174.2 58783.008

50000 918.5 55743.059

100000 2146 47716.682

Finished

mozilla/5.0 (x11; linux x86_64) applewebkit/537.36 (khtml, like gecko) chrome/38.0.2068.0 safari/537.36

Receive benchmark

Message size in KiB, Time/message in ms, Speed in kB/s

Connect wss://araiguma3.tok:30443/benchmark_helper

Opened

10 0.2495 41042.084

50 1.1635 44005.157

100 1.681 60916.121

500 12.72 40251.572

1000 28.36 36107.193

5000 150.75 33963.516

10000 289.6 35359.116

50000 1409.5 36324.938

100000 3452 29663.963

Finished

[rang...@googlemail.com]

I'd originally tried canary on my home Windows 7 32 bit machine. This didn't seem to improve things on that machine, but I will check again

Back on my Windows 7 Enterprise SP1  64-bit machine. I've installed canary and the good news it that I get faster results than chrome, but not as fast as firefox/IE (Results are below). I've put in the cypher info from the about boxes.

Any sped increase is good. I assume the canary changes will ripple into a release eventually. Are there likely to be any more changes ...? 

thanks.

=========================================

Windows 7 Enterprise SP1 : 64-bit

wss localhost:8081

Sending small "pull" request from client to server.

Server responds with 1 MegaByte binary blob.

 

----------------------------------------

Chrome : Version 35.0.1916.153 m   

default: 

128-bit encrytion; TLS 1.2 ; AES_128_GCM RSA

Frame Rate: 17.3

#enable-websocket-experimental-implementation:

128-bit encrytion; TLS 1.2 ; AES_128_GCM RSA

Frame Rate: 17.6 

----------------------------------------

Chrome : Version 38.0.2067.2 canary (64-bit)

default: 

128-bit encrytion; TLS 1.2 ; AES_128_GCM RSA

Frame Rate: 26.53 Frame Rate

----------------------------------------

Firefox 30.0

Frame Rate: 61.6

TLS_RSA_WITH_AES_128_CBC_SHA 128 bit keys

----------------------------------------

IE 10.0.9200.16899

Frame Rate: 104.4

Cannot see any cypher info.

----------------------------------------

==================================

[range matt]

With your help I now know a little bit about Ciphers and their negotiation, which is more than at the start of this discussion.

To confirm things, I tried hard coding the server cipher to SSL_CTX_set_cipher_list(ctx,"AES128-SHA"); Then the frame rates are as follows:

Chrome Version 35.0.1916.153 m :                49.75

Chrome Version 38.0.2068.0 canary (64-bit) :  53.15

Firefox Version 30.0 :                                    61.8

IE 30.0 :                                                       68.21

Despite some difference, the speeds for all browsers are now all in the same ball park, which is what is really important for me. I appreciate that the order of  performance may potentially change for different ciphers.  In this case I am in control of the server and will be able to decide on a suitable cipher list.

Thanks for all the help.

Matt

On 25 June 2014 22:13, Adam Langley <a...@google.com> wrote:

On Wed, Jun 25, 2014 at 3:16 AM,  <rang...@googlemail.com> wrote:
> Back on my Windows 7 Enterprise SP1  64-bit machine. I've installed canary
> and the good news it that I get faster results than chrome, but not as fast
> as firefox/IE (Results are below). I've put in the cypher info from the
> about boxes.
> Any sped increase is good. I assume the canary changes will ripple into a
> release eventually. Are there likely to be any more changes ...?

There's lots of numbers here but might is just be that the server
doesn't do AES-GCM very well and suffers when it picks it for us? (The
server picks the cipher suite in TLS, although it may be influenced by
the client's order.)


Cheers

AGL