codequest
asked on
memory, disk - scaling, performance - application architecture question
I am re-architecting an application that focuses on group collaboration around interactively building and annotating a complex diagram.
Average total data size for one group session for will probably be somewhere between 150KB and 1MB.
Currently the group session data is stored entirely in memory in a large object containing datasets and supporting variables. This data is synced to disk during diagram update/writes.
The data is kept in memory for fast diagram form refreshes (one participants does a small write, which might change the relationships on the diagram, which then has to be refreshed to all other participants).
My question has to do with performance versus scaling:
> If 1 GB can store 1000 concurrent sessions (in my dreams), it doesn't seem like that would be a scaling bottleneck i.e. the server would bog down first, or I could add servers if I ran out of memory.
> If I had to retrieve say 50KB from disk per diagram refresh (say one per second for each group session), it seems like that would be a big disk performance/scaling constraint.
So it seems like keeping the data in memory is almost necessary, to achieve scaling and maintain performance.
I'm trying to figure out if I've made some basic error in this thinking.
Any comments on these thoughts and assumptions would be appreciated.
Thanks!
Average total data size for one group session for will probably be somewhere between 150KB and 1MB.
Currently the group session data is stored entirely in memory in a large object containing datasets and supporting variables. This data is synced to disk during diagram update/writes.
The data is kept in memory for fast diagram form refreshes (one participants does a small write, which might change the relationships on the diagram, which then has to be refreshed to all other participants).
My question has to do with performance versus scaling:
> If 1 GB can store 1000 concurrent sessions (in my dreams), it doesn't seem like that would be a scaling bottleneck i.e. the server would bog down first, or I could add servers if I ran out of memory.
> If I had to retrieve say 50KB from disk per diagram refresh (say one per second for each group session), it seems like that would be a big disk performance/scaling constraint.
So it seems like keeping the data in memory is almost necessary, to achieve scaling and maintain performance.
I'm trying to figure out if I've made some basic error in this thinking.
Any comments on these thoughts and assumptions would be appreciated.
Thanks!
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
From a similar question I posted on another site:
I'm re-architecting an asp.net application from web forms into MVC, moving from 2006 to 2013 asp.net technologies. The primary function of the app is group collaborative construction of a complex graphic/text data set. The plan is to run multiple concurrent SaaS group work sessions from a cloud.
The core graphic/text set ("data set") would consist of about 5 related tables, that need fairly complex business logic and associated multi-table queries to turn them into useful display information. The content of this data set needs to be sent to all participants, in a slightly customized way for each participant, every time it is updated by any participant.
In terms of volume, say 10 participants per group, one data set change every several seconds (in one session), the entire data set building up to approximately 10KB by the end of the session, so say an average of 5KB to retrieve the entire core data set from disk (if that were the path) for each send to the browser. That may be high but there could be a wide range of volumes.
The resulting pattern for a single session is then relatively infrequent, small updates to disk, followed by 10 times as many relatively large sends to the browser.
I'm re-architecting an asp.net application from web forms into MVC, moving from 2006 to 2013 asp.net technologies. The primary function of the app is group collaborative construction of a complex graphic/text data set. The plan is to run multiple concurrent SaaS group work sessions from a cloud.
The core graphic/text set ("data set") would consist of about 5 related tables, that need fairly complex business logic and associated multi-table queries to turn them into useful display information. The content of this data set needs to be sent to all participants, in a slightly customized way for each participant, every time it is updated by any participant.
In terms of volume, say 10 participants per group, one data set change every several seconds (in one session), the entire data set building up to approximately 10KB by the end of the session, so say an average of 5KB to retrieve the entire core data set from disk (if that were the path) for each send to the browser. That may be high but there could be a wide range of volumes.
The resulting pattern for a single session is then relatively infrequent, small updates to disk, followed by 10 times as many relatively large sends to the browser.
ASKER
@connollyg
re what about memory failure: the app currently uses DataSet/TableAdapter; the writes are all updated to disk at the time they occur.
re what about memory failure: the app currently uses DataSet/TableAdapter; the writes are all updated to disk at the time they occur.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I've concluded that performance and scaling questions are completely non-trivial, and so my question can't really be conclusively answered. Inputs here have been valuable in reaching that conclusion, so points are rewarded accordingly.
ASKER
Thanks for input.
1) I believe I considerably overestimated the amount of data that would be actively worked on and presented. Better estimate would be 10KB. This was calculated by considering table rows, fields, field usage and field sized (higher estimates did not account for null fields).
2) Data is currently maintained in memory in a ADO.NET DataSet that has 5 linked tables.
Unfortunately I have only a prototype and am unable to test high volumes in order to use the utilities you recommend.