What do you for first load page with have too many data

codingvn

Hi LS team,

I have met the problem with LS on client application.
I build a stock price board online.

When I loading client with IE browser then my CPU overload 100% and download data is very slow

- My application is about 168 items. schema has 52 field. So data is very big with first load.

But with firefox, everything is okie. The problem only happen with IE.

I dont want show some items as http://www.lightstreamer.com/vb/showthread.php?t=333 (use Grid)

I want show all items with first load. If you have solution, please help me.

Thank you very much.

Mone

Hi,

please note that the heavy part on the browser is the DOM manipulation (and 8736 fields are a lot of work).

first of all try to remove all visual effects if any on the snapshot events with something like this:

in the onItemUpdate handler
[syntax="JS"]if (updateItemInfoInstance.isSnapshot()) { //first update for this item
updateItemInfoInstance.addField("illuminate_extra_field","OFF",false);
}[/syntax]

in the onChangingValues handler
[syntax="JS"]var illuminate = visualUpdateInfoInstance.getFormattedValue("illuminate_extra_field");
if (illuminate == "OFF") {
//don't illuminate the cells
}[/syntax]

let me know if this helps.

codingvn

@Mone, Wrote: Hi,

please note that the heavy part on the browser is the DOM manipulation (and 8736 fields are a lot of work).

first of all try to remove all visual effects if any on the snapshot events with something like this:

in the onItemUpdate handler
[syntax="JS"]if (updateItemInfoInstance.isSnapshot()) { //first update for this item
updateItemInfoInstance.addField("illuminate_extra_field","OFF",false);
}[/syntax]

in the onChangingValues handler
[syntax="JS"]var illuminate = visualUpdateInfoInstance.getFormattedValue("illuminate_extra_field");
if (illuminate == "OFF") {
//don't illuminate the cells
}[/syntax]

let me know if this helps.

Thank you for your help !

I tried with the your guide, I can remove visual effect change background color with first loading page (It's very good :Smile_Ag: ). But with some visual effects : set price color, format value null ... they always execute.

- I have idea : Can you bind about from 20 to 30 rows one time, then they bind continue to data end. Because If i bind about 20 items. It's very fast. If can, please guide for me.

Thank you very much.

Dario Crivelli

If I understand well, you would like to defer some subscriptions, so that 20 items are subscribed to immediately and the remaining 148 items are subscribed to in the background.
There is no facility by our library for this task; it must entirely be done through custom code, by separating the items in multiple tables and governing the timing of the various "addTable" calls.
Note that the cells on the page should be assigned the "table" attributes accordingly. After all subscriptions are done, nothing should reveal that the cells pertain to different tables.

Consider that, in case of connection problems, after a successful connection recovery, the library will try to restore all subscriptions and in this case the requests will be issued alltogether.

quanhm

Hi all,
I'm currently having the same problem as codingvn. I tried to split the list of items to different sub-lists and load these sub-lists one by one until the last,this is for minimizing the number of processing cells at the same time, and of course the visual affects (changing background-color of cells which have changes in value) are disabled if the last item of the last sub-list doesn't receive its first values. But the case is not improved much for IE browsers because there is a lot of changing cells in real-time trading hour, and that means the browser will have heavy DOM manipulation. I quickly recognize that IE browser is extremely weak in processing concurrent javascript code especially with a big bundle of HTML cells like Lightstreamer cells in my case. The paging and Grid solution are not approved by our customer, do you have any other solution ?

Alessandro Alinone

Dear quanhm,

It is clear that AJAX applications are based on pure JavaScript technology (together with HTML, DOM, CSS, etc.), which is an interpreted language. So its execution is undoubtedly slower than tradition thick applications (based on Java, .NET or native code). What we see in our experience, is that developers delving into the AJAX world tend at first to do an exact porting of their traditional thick applications to the Web. But AJAX cannot be used for that, because the porting should take into consideration performance. So, after the first attempts, they realize how to change the architecture or the requirements of the application. So, here are some general guidelines (which apply not only to Lightstreamer but to any AJAX and Comet solution):

Visual updates are pretty heavy on the browser, so they should be limited to a reasonable quantity. For this purpose, two techniques can be used:

- Limit the maximum update frequency for each displayed item. Lightstreamer allows to set a maximum frequency, reducing the number of updates. Typical frequencies for browser-based finance applications range from 1 to 3 updates per second. But if you need to have many many concurrent cells in the same page, with a slow hardware or a weak browser, you can choose lower frequencies. You could reach a similar effect by limiting the overall bandwidth of the push session. The conflation capabilities of Lightstreamer allows you to reduce the number of updates without sacrificing data consistency and the degree of real time.

- Limit the number of items displayed on the same page. A design pattern used to limit the number of subscribed items is based on pagination (splitting a long list into different pages), or, better, on grids. A grid is a way to handle a long table of items where only the visible part is actually subscribed, with a great improvement in performance (an example is http://app.lightstreamer.com/GridDemo/).

Also, the kind of visual effect (highlighting, fading, style change, etc.) and the font used can affect performance in a significant way.

Furthermore, different browsers exhibit pretty different performance. The JS engine of Internet Explorer and Firefox have different efficiencies (with IE7 and FF2 the gap was partially filled, but previously IE was much slower than FF).

We have gone through this optimization process with our customers in the finance industry several times. Starting from a potentially slow front-end and changing its design until a good trade-off between quality of information and performance was reached. Until now, it has always been possible to find a reasonable trade-off.

Cheers,
Alessandro