Page 2 of 2 FirstFirst 12
Results 11 to 19 of 19
  1. #11
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    1,089
    May you please provide us with more details on the expected and observed behaviour? What makes you feel that the update sequence is unnatural?
    Note that if your application sends 2-3 kb fields and there are as many as 256 fields in an item and the fields change frequently, then the bottleneck might be on the client side as well.
    Are those fields images that the client renders on the screen?
    If the different fields are not meant to be updated by the client at the same time, you could rather try to define 256 items with one field each and see if the final effect is better.

  2. #12
    Senior Member
    Join Date
    Jan 2008
    Location
    Mumbai
    Posts
    39
    hi,

    our scenario is like this,
    we are continuously capturing screen shots and pushing them to server(we are capturing a screen shot for every 250 milli seconds).

    So, for that we made an application which divides each screen shot into 256 image blocks and push them onto server continuously one by one in base64 format by using tcp/ip socketing.
    And when client browses to LS Server URL he sees the screen shots which we are capturing at other end.

    We are capturing & sending the screen shots and client can see those screen shots perfectly but client is taking some time( 8 to 10 seconds) to see what we captured.

    So,here my question is that can we do any thing at LS server end to reduce that time taken by client browser to see captured images(ie.8 to 10 sec).

  3. #13
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    1,089
    Is 10 seconds the total time from taking the screenshot to seeing it displayed on the client? Is the client at 100% CPU during the process? Are you using the Javascript Client Library? (note that the Javascript Client Library is not meant for getting large amounts of data and may not be efficient for this task).

    Lightstreamer allows you to operate in two directions:
    • Sending the image slices independently. If you can display the image slices independently, then you can request them in such a way that each one comes in a different update and can be displayed as soon as possible, without the need to wait for the other images.
    • Slowing the frequency of the screenshot updates. The Javascript Client Library has a mechanism to adaptively slow down the update frequency when the client can't keep the pace of the updates, though it has never been tested on very big updates.


    But I'm not sure that the above is the kind of manipulation you are looking for. May you please clarify furtherly?

  4. #14
    Senior Member
    Join Date
    Jan 2008
    Location
    Mumbai
    Posts
    39
    yes,

    we are using Javascript Client Library , is there any replacement for this because every 250 millisec. we are pushing the 256 image blocks. OR shall we go for dotnet client library to make image appearence as live.

  5. #15
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    1,089
    The Javascript Client Library was designed with textual data in mind; more generally, it was not designed with huge amounts of data in mind. Hence, we have no benchmarks for a usage of your kind. May you please confirm that your client CPU reaches 100% during the processing?
    May you also please confirm that you are not interested to an adaptive slowdown of the refreshing frequency based on the client capability?
    If this is the case, then we just suppose that part of the overhead is due to the Javascript interpreter, so that a dotnet based client may be more efficient. By the way, if you just turn off image rendering on the client but still subscribe to all the data what do you observe on the CPU of the client machine?

  6. #16
    Senior Member
    Join Date
    Jan 2008
    Location
    Mumbai
    Posts
    39
    on client side the Usage of CPU is not 100 %

    when I subscribe to images on client side CPU's average usage is 7% and
    when I subscribe to data without images CPU's average usage is 5%.

  7. #17
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    1,089
    As you have removed all bandwidth limits (which, with very huge data, could introduce significant delays)
    and you haven't put any stringent frequency limit,
    there is nothing in Lightstreamer that can cause delays of several seconds.
    Therefore, there must be a bottleneck or a blocking behaviour somewhere else.
    However, Lightstreamer may be involved only in concurring to causing a CPU bottleneck; but the client (which is the most sensitive part) seems not to be overwhelmed (unless you are using a multi-CPU machine; please confirm).
    Hence, there is still no evidence that Lightstreamer is involved in the overall delay.
    Before investigating further, may you please try reducing the load (requesting and rendering only one of the 256 subimages, for instance) and see if there is no delay in this case?

  8. #18
    Senior Member
    Join Date
    Jan 2008
    Location
    Mumbai
    Posts
    39
    I am capturing and dividing the whole desktop image into 256 small image blocks,and sending them to LS server in base64 foramt and again I am extracting and joining them as a single image at LS Client side this is my original scenario.

    And as you said to check a single image block ( means a single field in my Item), in that case when I am pushing Image blocks onto server they all are pushed randomely (means the 1st field is not going update first,last ie.256th field is not going to up date in last,. They all are updated randomely).

    So,when I am checking with single image block the LS server is taking almost same amount of time(used to take push all image blocks) to push the data (image block) onto client.

    And I am running LS server on one machine and checking the data by running client on other machine.

  9. #19
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    1,089
    Unfortunately, I can't understand the point about random updates of the image blocks and why this affects the delay.

    When you tried with a single image block, you only reduced the "schema" requested on the client side to one field (the upper left block, for instance), is it right? And didn't you get any latency improvement?

    Commenting this from Lightstreamer point of view, if we rule out client-originated overhead, it remains to check for server-originated overhead, though we don't expect it to be higher. Please, furtherly reduce the load by only pass a single image block (the same block as in the client schema) to the Update method call on the Remote Data Adapter side and see what happens.
    If the delay is still high, we can move to Server log analysis (which is difficult now, when all image blocks are involved).

 

 

Similar Threads

  1. dotnet demo Portfolio-Basic not work fine
    By lisicnu in forum Adapter SDKs
    Replies: 3
    Last Post: December 8th, 2011, 03:41 AM
  2. Difference between createEngine and seekEngine
    By webfg in forum Client SDKs
    Replies: 2
    Last Post: April 13th, 2009, 12:07 PM
  3. DotNet Adapter
    By VietXuan in forum Adapter SDKs
    Replies: 3
    Last Post: November 5th, 2007, 10:41 AM
  4. Unable to create New DotNET Adapter
    By shobha in forum Adapter SDKs
    Replies: 4
    Last Post: August 13th, 2007, 02:32 PM
  5. Lightstreamer Moderato Released!
    By Alessandro in forum General
    Replies: 0
    Last Post: March 27th, 2007, 12:42 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
All times are GMT +1. The time now is 04:08 AM.