Websockets message throughput limit?

[ReVaN01]

Ok so here are some tests I carried out with better proof of what is going on. Excuse me for my previous post, as I am still experimenting with settings etc..

These are my server settings for the streaming section:

<max_delay_millis>33</max_delay_millis>
<default_keepalive_millis>5000</default_keepalive_millis>
<min_keepalive_millis>1000</min_keepalive_millis>
<max_keepalive_millis>30000</max_keepalive_millis>

and these are my settings for the Smart Polling section:

<max_polling_millis>0</max_polling_millis>
<max_idle_millis>30000</max_idle_millis>
<min_interpoll_millis>0</min_interpoll_millis>

I first listened to the data adapter using WS-STREAMING connection which I set to send a message every 33 ms. Then I used wireshark to check what the server is sending to the client using this filtering query:

ip.src == { SERVER IP } and ip.addr == { CLIENT IP} and tcp.port == 8080 and frame.time >= "May 28, 2012 19:20:00" and frame.time <= "May 28, 2012 19:21:00"

That means that I filtered for all messages sent on port 8080 in 1 minute time range. I was expecting to get 1800 packets sent from server to client, since I am sending at a 33ms interval, so that should be 30.3 msgs/s * 60seconds = ~1800. Instead I got 1700packets which is 28.3 msgs/second. That is pretty close to what I was expecting and it actually is a very good performance.

The exact same test was done again using HTTP-POLLING forced connection instead. The result was 742 replies in one minute, hence 12.36 message per second.

Am I right in assuming that the request limit for polling is 12.36 messages per second on my computer environment? I'm pretty sure websockets could keep going up

[DarioCrivelli]

In a local test on my PC, I could reach higher rates in HTTP-POLLING.
Are network roundtrip times involved in your test?
Or any elaboration time on the client side?
Otherwise, we think that you should have room for improvement.

Anyway, I must correct myself on one point.
A couple of posts above, I wrote that in the default configuration there are no pauses introduced by the Client or Server apart from <max_delay_millis>.
But, actually, the JavaScript Client Library also has a similar pause, which is also aimed at improving the efficiency; this pause is 50 ms; so, at the current stage, you are going to face an upper limit of 20 polls per second.

However, we acknowledge that your use case is getting increasingly important, so we are planning to remove the limitation since the next update of the Colosseo preview release.
In the meantime, we encourage you to obtain a limit-free version of the library by applying the following change to the current version of the library:
- open lightstreamer.js in a text editor
- ensure from the heading that it is Version 6.0 b2 Build 1525
- find the following string: if(this.Uv){var j=n.uC()-this.Uv;if(d>j)d-=j;else d=1}
- replace d=1 with d=0 at the end of the string

[ReVaN01]

I performed some new tests and I totally eliminated DOM modifications (HTML 5 canvas use) which I realized they were slowing the whole polling process down. Surprisingly I got an almost constant 20 message per second! Then I read Mr Crivelli's post and understood why it was stopping at 20..

I performed a test which basically involved a JavaScript loop making calls at different timescales. I could scale up to 50 requests per second while still getting a server response without delays (on a local network). If I added more request per second I started to get delays and hence replies from server started getting mixed and not in order.

I am sure lightstreamer can scale up this much with polling as well and I will try the javascript library modification you suggested to test this

Thanks a lot, your replies were very helpful.

[ReVaN01]

Yes I can confirm that with your javascript library modification I could scale up to 30 messages\second with Polling instead of 20! and I did not test for more because I don't need more than 30

Thanks