It wasn’t long ago that I ran into a strange issue with Chrome. My Jasmine tests were failing because the timeout on the asynchronous actions was too short for Chrome, even though they worked perfectly fine for Firefox. This led to me writing some tests to see if Chrome’s WebSocket implementation was slow which gave some pretty interesting results. I’ve also heard some interesting results from my readers, so I decided to investigate some more.
This time we’re looking at the time it takes to send and receive messages. I had some people tell me that they were getting slow messaging speeds, so I decided to add another little test into the project that I had already made to test Socket.IO connections. The project is on GitHub if you’d like to run it on your own computers.
Let’s take a look at the code for the test. I probably should have done this in the last post, so that there might actually be something to learn, but oh well.
It’s really really simple. When we connect, send a message (named with an odd number) to the server with some miscellaneous data. We do the same thing whenever we receive any messages (with even number names) from the server: just send another message back (with odd number). We do this 8 times, and then disconnect. The server is set up exactly the same way. When it receives a message (with odd number), it sends a message back (with even number).
Super simple, right? Well, I ran these tests and I couldn’t find a browser that didn’t get through all of these messages in more than 10ms on average. That seems REALLY fast, and it is, but it’s on a local machine, so it’s not like the messages had far to go.
Anyway, the results seemed pretty conclusive to me: sending messages isn’t hindered in any way. Then again, I only had the connection slowness on a single browser on a single computer, while all the other browsers on all the other computers ran just fine. So there might be someone out there who will run this test and see very different results.
Just to let you all know, the tests work a little differently than before. Previously the tests ran automatically and were output in the console, but I’ve changed that for several reasons.
- I added another test, so I wanted the user to be able to choose a test and run just the one.
- If the console wasn’t open when the test first ran, you might have to refresh after opening the console in order to get the results to show up.
- Consoles are slow (especially Firebug). When running the connection test in Firefox with different consoles open, I got these average results for the WebSocket connection speed:
|With Built-In Console||30-85ms|
|With Firebug Console||450-800ms|
I love Firebug, but this has been bugging (no pun intended) the heck out of me. Firebug’s performance has been horrible in the last several months. I’m glad that (especially in the Nightly Firefox release) the built-in console and web developer tools have gotten so much better recently. This allows me to not need to open up the slow monolith that Firebug has become for most of the quick things that I need to do.
Anyway, due to these reasons, I moved the test output into a
textarea and the tests run when you click a button. No big deal, but I thought it was worth mentioning.
It doesn’t seem to me that there are problems with the message sending aspect of WebSockets to me, but there’s no reason to believe that it isn’t causing problems on someone else’s computers, especially considering it only impacted Chrome on one of my computers. Let me know your results in the comments below. Maybe try setting up the server on a separate machine so we can add some lag time in to see if that makes a difference. God Bless and happy coding.