How to send data to single client rather than all?

Mone

Ops,

you're right, I had a false memory, that getItems does not personalize the item name cause we decided to not user user names for our demos, my bad :o

About the "broken" name, is called that way cause that metadata adapter inherits from the LiteralBasedProvider whose impleemtnation of getItems is to split the received string on the space character (hence the "broken" name as "broken in pieces").
Using such metadata adapter permts to use an "Item List" on the client.

see http://www.lightstreamer.com/docs/client_javascript_uni_api/Subscription.html for some details:

an Item List is an array of Strings each one representing an item. For the Item List to be correctly interpreted a LiteralBasedProvider or a MetadataProvider with a compatible implementation of getItems has to be configured in the associated Adapter Set.

kpturner

Mone ......my bad :o

OMG!! An Italian using an Americanism. The world is falling apart :rolleyes: :Smile_Ad:

Alessandro Alinone

kpturner OMG!! An Italian using an Americanism. The world is falling apart :rolleyes: :Smile_Ad:

Heheh:cool:

Mone

blame american series for that :Smile_Ag:

kpturner

So back to the subject at hand, this very simple echo server is now working fine. What I need to address now is performance. What I have found with other evaluations is that I can send a very quick burst of separate messages to the server and the echos come back almost instantly. With my Lightstreamer echo server, if I send a very quick burst of separate messages to the server, the echoed responses plod back very slowly. I am using the logger on my echo data adapter to trace a message every time it is echod back, and I can see that the server is responding extremely fast. If I send a burst of 100 messages, my data adapter has processed all the "listener.smartUpdate" calls almost instantly - but the data is plodding back to my browser very slowly.

In other words:
* Burst of 100 outbound messages
* Data adapter has echoed them all back virtually instantly
* 100 messages arrive sequently on my browser very slowly, like only one or two per second

Something is slowing matters down, and it doesn't seem to be the data adapter itself. What should I be looking at to try to work out what is going wrong? Possibly the configuration of subscription? Any pointers?

Giuseppe Corti

Are you testing with "Moderato" edition of Lightstramer? Please note that this edition has the limitation of up to 1 update per second for each item.
In your performance test you should use the "Vivace" edition.

If you're already using the "Vivace" edition let us know that so we'll investigate further about the configuration of subscription.

kpturner

I am using Moderato :Smile_Ac:

I will change and let you know the result.

kpturner

Yes, changing to Vivace made a huge difference - thanks. A sneeky marketing ploy that we could do with adopting ourselves :Smile_Ab:

kpturner

Moving on, I am now using Vivace to test with and I an getting fast throughput for a single client.

However, if I open two browsers (say, one Firefox and one Chrome) and fire off 100 echos simultaneously on each browser, one of the browser sessions hangs until the other one has got all its responses. It is as if the two browsers are both processing data through the same thread on the server. So one does not get any response from the server at all until the first browser session has had all its messages echoed back.

Clearly I have something misconfigured (or I have coded something incorrectly), because that would be fairly useless in a production environment.

Any pointers?

Giuseppe Corti

Hi kpturner,

The scenario you describe is indeed unexpected; can you post here an extract from the log of the Lightstreamer server after you have set the "LightstreamerLogger.subscriptions" and "LightstreamerLogger.pump" loggers at DEBUG level?
This will allow us to understand the dynamics between adapter and server, and so identify the bottleneck.

kpturner

I have changed lightstreamer_log_conf.xml thus:

<logger name="LightstreamerLogger.subscriptions" level="DEBUG"/>
<logger name="LightstreamerLogger.pump" level="DEBUG"/>

but I do not see any debug information in my log :Smile_Ac:
Have I done it incorrectly?

kpturner

It would be interesting (for my future reference) to find out why my changes to the logging did not accomplish anything.

However, I seem to have moved on a little with my perceived "blocking" issue. My stress test was a tight loop in javascript constantly clicking a button to send the message to Lightstreamer. When I changed this to introduce a tiny 1ms time lapse between each click/send, both browsers started to work simultaneously. In other words, I was sending/receiving in both browsers with no blocking. So this tells me that the issue was not with the server at all, but with my own PC processor. In fact, when I switched off DEBUG in my adapter log config it processed the echos reasonably quickly. 5000 echos simultaneously on Firefox and Chrome, with Firefox completing in 30 seconds and Chrome in 25 seconds.

Mone

Well, assuming the rest of the file is not changed then your configuration is correct and you should see such debug logging in the log files (NB: the log on the console would not change with such settings as the console -LSConsole- appender is only configured for init and license categories).

As per the issue with the strict loop, I think that's not a problem with your CPU: please note that JavaScript is mono-thread and that our library executes "commands" (see as an example the sendMessage lifecycle documentation) asynchronously so that if you keep the CPU occupied with a huge loop our library will not have any chance to send the messages to the server as it will receive its share of CPU only when such loop is terminated.

HTH

kpturner

I see. I was expecting to see the messages in the console but I can see them in the logs. Thanks.

Interesting about the loop. I was not expecting it to be an issue between two different browser instances despite the fact that JavaScript is mono-threaded. Thanks for the info.