DbGrid and continuos chat with server...

[Stemon63]

Hi,
when user scroll records in dbgrids or navigate column by column, Unidbgrid calls continuos server.
Tricky Question: in a Big application with a lot of users (thousands), how many users are needed to pull down a server, if all users "play" by scrolling and browsing continuously on a grid (with many records)?
 

[Hayri ASLAN]

1 hour ago, Stemon63 said:

Hi,
when user scroll records in dbgrids or navigate column by column, Unidbgrid calls continuos server.
Tricky Question: in a Big application with a lot of users (thousands), how many users are needed to pull down a server, if all users "play" by scrolling and browsing continuously on a grid (with many records)?
 

Hello

You may record a session while "play" by scrolling and browsing continuously on a grid and run it with stress test tool to see how your app is handling it

[Stemon63]

HI Hayri,

I known very well stress tool, but I think that there is time to "rethink" some behaviors, which are harmful when  we want publish applications with a high number of users.
It is clear that Unigui chats with the server because it has to update both the data and the current record, otherwise the data logic on the server cannot be used.

But I think it's time to introduce optional behaviors to perform operations on the client's store data (ExtJS store), with the management of the grids only on the client side, with the possibility of carrying out the cached updates on the "all-in-one" server call, and without any call to server events during input and navigation, unless expressly desired by the programmer.
Only in this way will we be able to manage data traffic with the server efficiently, according to our needs.
I don't think it's acceptable to have 1000 users scrolling through grids with a lot of data for consultation, and maybe inserting or modifying only a few records, generating continuous traffic with the server. Alternative solutions must be found to "lighten" the situation in certain cases.
A kind of "cached updates" between client and server can be an excellent solution, for start.
(We also have to deal with competing products on the web, which behave totally differently, as you know...)

Sorry for my poor English :-)

[Stemon63]

HI Hayri,
With Stress Tools Unigui works very well... also with a lot of sessions.
But I want to avoid the excessive number of calls to the server when they are not needed. In my case, if I don't have data to display in other editors, and if I just have to search in a grid, there is no need to synchronize the server for each row and column movement, because I don't apply calculations or other controls. For this, I have adopted the system already addressed in another thread:

function select(sender, selected, eOpts) { return false }


For now this resolve my need on simple search lists (40% of application's forms) and optimize server calls :-)

Thanks a lot