UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36
Example URL:
N/A
Steps to reproduce the problem:
1. Create a simple websocket server that writes blobs repeatedly. For example, in go:
package main
import (
"net/http"
"golang.org/x/net/websocket"
)
func speedtestHandler(ws *websocket.Conn) {
var s []byte
s = make([]byte, 1000000, 1000000)
for {
websocket.Message.Send(ws, s)
}
}
func main() {
http.Handle("/echo", websocket.Handler(speedtestHandler))
err := http.ListenAndServe(":6502", nil)
if err != nil {
panic("ListenAndServe: " + err.Error())
}
}
#########
2. Start the server on a Linux box, connected at 1Gbps to an Ethernet switch.
#########
3. Create a simple HTML page that downloads blobs from this websocket server and prints the throughput (changing the wsUri link accordingly to the Linux server's IP). For example:
<!DOCTYPE html>
<meta charset="utf-8" />
<title>WebSocket Test</title>
<script language="javascript" type="text/javascript">
var wsUri = "ws://192.168.2.50:6502/echo";
var output;
var count = 0;
var start = 0;
var realstart = 0;
var size = 1000000;
function init()
{
output = document.getElementById("output");
testWebSocket();
}
function testWebSocket()
{
for(var i=0; i<4; i++) {
websocket = new WebSocket(wsUri);
websocket.onopen = function(evt) { onOpen(evt, this) };
websocket.onclose = function(evt) { onClose(evt, this) };
websocket.onmessage = function(evt) { onMessage(evt, this) };
websocket.onerror = function(evt) { onError(evt, this) };
}
}
function onOpen(evt, ws)
{
writeToScreen("CONNECTED");
start = Date.now();
doSend(""+size, ws);
}
function onClose(evt)
{
writeToScreen("DISCONNECTED");
}
function onMessage(evt, ws)
{
//writeToScreen('<span style="color: blue;">RESPONSE: ' + evt.data.size + '</span>');
//websocket.close();
if (evt.data instanceof Blob) {
count++;
if (Date.now() - start < 5000) {
doSend(""+size, ws);
} else {
var duration = Date.now() - start;
writeToScreen('Transferred ' + (count*size) + ' bytes in '+duration+'ms. Speed: '+(((count*size)/(duration/1000))*0.000008)+' Mbps');
ws.close();
}
}
}
function onError(evt)
{
writeToScreen('<span style="color: red;">ERROR:</span> ' + evt.data);
}
function doSend(message, ws)
{
ws.send(message);
}
function writeToScreen(message)
{
var pre = document.createElement("p");
pre.style.wordWrap = "break-word";
pre.innerHTML = message;
output.appendChild(pre);
}
window.addEventListener("load", init, false);
</script>
<h2>WebSocket Test</h2>
<div id="output"></div>
#########
4. On a Mac OSX machine, connected with at 1Gbps via ethernet to the same network, navigate to the web page just created.
#########
5. Observe the speed measured
What is the expected behavior?
On a 1Gbps Ethernet network, you should see ~945Mbps download speed recorded (at the application layer).
Latest Chrome, Firefox and IE on a PC all see ~945Mbps. Firefox on Mac OSX also records ~945Mbps. Recent versions of Chrome on Mac OSX do not!
What went wrong?
Chrome on Mac OSX is seeing very degraded performance when fetching binary data via websockets. This problem was introduced sometime between Chromium 47.0.2526.111 and 48.0.2564.97. Versions since 48.0.2564.97 are recording ~600Mbps on a 1Gbps Ethernet network. Versions prior to this are receiving data at ~945Mbps, as is expected.
A breakdown of test results on different versions of Chromium is attached.
Did this work before? Yes 47.0.2526.111
Chrome version: 49.0.2623.75 Channel: n/a
OS Version: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.75 Safari/537.36
Flash Version: Shockwave Flash 20.0 r0
The use case is a websockets based speed test.
|
Deleted:
Chromium Mac 2016 03 04.xlsx
11.1 KB
|
|
|
Chromium Mac 2016 03 04.xlsx
11.1 KB
Download
|
Comment 1 by b...@chromium.org
, Mar 4 2016Labels: Performance