Jump to content

server farm


Wilton Ergon

Recommended Posts

On 9/13/2021 at 4:09 PM, Pep said:

Wow! 23303 active sesssions!!

 

23303 active sessions! Wow!
How many datasets do you leave open on servers at the same time? 😉 How many active database connections?😉
Am I right to ask Farshad for a disconnected clientdataset (on client)?😆😄

Link to comment
Share on other sites

  • Administrators
27 minutes ago, Stemon63 said:

23303 active sessions! Wow!
How many datasets do you leave open on servers at the same time? 😉 How many active database connections?😉
Am I right to ask Farshad for a disconnected clientdataset (on client)?😆😄

Our tests are done with TClientDataset, so it doesn't simulate a real world DB application.

For a real world DB app you should use connection pooling or a middle tier to solve the database scalability problem.

Link to comment
Share on other sites

the load division is calculated according to the maximum number of nodes that each server will go up, if this is proportional to the total nodes of all servers, this would be the calculation that each server would have to have active sessions, such as a stress test, I imagine that all sessions were loaded once and were active.
let us know the logic used for dividing this workload.

 

and the way I did in this little spreadsheet?

image.png.12e5319f97dcbf8879d521f0c89c5c9b.png

Link to comment
Share on other sites

  • Administrators
29 minutes ago, wilton_rad said:

the load division is calculated according to the maximum number of nodes that each server will go up, if this is proportional to the total nodes of all servers, this would be the calculation that each server would have to have active sessions, such as a stress test, I imagine that all sessions were loaded once and were active.
let us know the logic used for dividing this workload.

 

and the way I did in this little spreadsheet?

image.png.12e5319f97dcbf8879d521f0c89c5c9b.png

You should take existing Nodes into account:

image.png

Based on tested application some Nodes may not become active. Above setup is a multi-application setup. Some applications are not used during the test.

Link to comment
Share on other sites

On 9/14/2021 at 7:33 PM, Farshad Mohajeri said:

Our tests are done with TClientDataset, so it doesn't simulate a real world DB application.

For a real world DB app you should use connection pooling or a middle tier to solve the database scalability problem.

Yes Farshad, you are correct.

But to reach your numbers in reality, it is necessary not only to operate with disconnected datasets  from the database after quering (autodisconnect: = true or Connection.disconnect), but also close  the active datasets that remain in memory all the time, in fairly common situations.
It takes exactly yours light-weight version of DBgrid, with procedures that Loads dataset in client store, CLOSE THAT DATASET (also via server code) and permits an Applyupdates  that manage the Json Delta for update DB on  server (under user control) when the client job is done.
A remark:
if I scroll records on grid, the data in the corresponding editors (detail) must be fetched from the store and not calling the server, optionally. 

The management of the ExtJs store via component would be convenient for sending very fast lookups or managing it as a real dataset.

In the meantime there is no traffic with the server without 23303 * 20 (for example) = 466060 datasets active on the farm 😃
Combining the traditional system with this new one, according to the needs, I think I can manage all my needs, saving a lot of bandwidth and above all, a lot of resources.
In practice it would be perfect.
(sorry for my english...)

 

  • Grid enhancements
    • Grids and specifically DBGrids are key components of uniGUI. For many developers grids are the most vital element of the application. For this, we will re-visit grid components, explore and discuss all opportunities to enhance the grid behavior. Including better data-input, native filtering, client-side filtering, infinite scroll and etc.
    • We also have plans to introduce a light-weight version of DBGrid which will allow developers to have more control on the grid. Many of the tasks in existing version of uniGUI DBGrid is fully automated. In the light-weight grid those tasks will be left to developers to handle. Such as posting data to the back-end dataset and etc.
Link to comment
Share on other sites

3 hours ago, Farshad Mohajeri said:

Good thing is that an application can exist in any of the servers in the server farm. When you call it HyperServer finds it and internally redirects you to that server.

In addition to the standard comfortable use, I see it very useful in the case of a large container portal that groups different applications such as modules, divided by area, which are shown in the frames. Really useful news.

  • Like 1
Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...