 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / Performance / March 2005scalable state-management
Could someone point me in the direction of good discussions on scalable state management solutions? Specifically, pros and cons of following strategies: Strategy 1 : temporary business-objects are implicitly stored in RAM, "permanent" business objects are explicitly stored in SQL-Server Strategy 2 : both temporary and permanent business-objects are implicitly stored in SQL-Server Strategy 3 : both temporary and permanent business-objects are explicity stored SQL-Server By "explicitly stored" I mean that ADO.NET is used to load/save business objects to/from SQL-Server db-tables. By "implicitly stored" I mean that persistent business-objects implement ISerializable and are stored in session-state. The state-server is either implemented as an out-of-process RAM state-server, or an out-of-process SQL-Server state-server. An example of a temporary business-object is a shopping-cart collection of items before the customer has committed to purchasing them. An example of a permanent business-object is a shopping-cart colletion of items after the customer has committed to purchasing them. I have not built a highly scalable ASP.NET web-app, but it occurs to me that: 1. accessing a DISC state-server (either explitly or implicitly) is much slower than accessing a RAM state-server 2. a DISC state-server is effectively infinitely expandable 3. a RAM state-server is limited to the maximum RAM supported by the OS Question: can special machines be built that exceed the basic OS RAM maximum? Question: is it possible to split a RAM state-server across multiple machines? i'll point you to the distributed /xml webservices book my mathew mcdonald. its thorough  SignatureRegards, Alvin Bruney [Shameless Author Plug] The Microsoft Office Web Components Black Book with .NET available at www.lulu.com/owc _________________________ > Could someone point me in the direction of good discussions on scalable > state management solutions? [quoted text clipped - 38 lines] > Question: is it possible to split a RAM state-server across multiple > machines? > Could someone point me in the direction of good discussions on scalable > state management solutions? [quoted text clipped - 36 lines] > Question: can special machines be built that exceed the basic OS RAM > maximum? The big picture here is that with x64, memory limitations on processes are an artifact of history. In the very near future you will be able to buy as much RAM as you need for your web caching. Dvid Hi David, and thanks for the response. Ok, but even if x64 makes possible unlimited RAM on a single state-server, does not a SQL-Server state-server still have one big advantage advantage in that the latter can distribute session data across multiple physical servers, mitigating the consequences of a single server going down ... ... and isn't it also true that only a SQL-Server state-server can provide some measure of recovery from crashes ("some measure", because typically (for performance reasons) full logging is not desirable, and neither replication, log-shipping, nor failover clustering can provide good redundancy for the highly dynamic session-state data). >> Could someone point me in the direction of good discussions on scalable >> state management solutions? [quoted text clipped - 44 lines] > > Dvid > Hi David, and thanks for the response. > [quoted text clipped - 8 lines] > replication, log-shipping, nor failover clustering can provide good > redundancy for the highly dynamic session-state data). Yes, there still are some advantages there. But "PlanA", using a single web server with in-memory session state, suffices for more and more deployment scenarios. There are still times to use "PlanB" and "PlanC", but more and more applications will be able to make a design-time commitment to "PlanA", and rely on hardware scaling to make it happen. David When you say Plan A "in-memory session state" do you mean use of Session State in addition to use of direct read/writes to SQL-Server ? Just using in-memory session-state would seem to be problematic for any web-app that involves purchases: at some intermediate point in the purchase sequence you're going to have good reason to save information to database. For example, right after obtaining credit-card approval (right before sending down the page asking for final approval) you're going to want to save data on the customer's order to database. This is because if a crash occurs before the user sends back the final approval page, credit has still been allocated on the card and without will not be removed by card company until 48-72 hours. Many customers don't understand why their credit is reduced when they didn't make a purchase, and they will call or e-mail demanding an explation. To assist them, records of the aborted transaction need to be present in the database. Sometimes it is possible for the vendor to call the credit-card company and have the credit reinstated more quickly than is the general rule. >> Hi David, and thanks for the response. >> [quoted text clipped - 17 lines] > > David > When you say Plan A "in-memory session state" do you mean use of Session > State in addition to use of direct read/writes to SQL-Server ? Yes. > Just using in-memory session-state would seem to be problematic for any > web-app that involves purchases: at some intermediate point in the > purchase sequence you're going to have good reason to save information to > database. Yes, of course. The results of any transaction which represent a change in the "durable application state" must be immediately written to the database. It's only the user's session state (cached data, navagation history, user profile, shopping cart, etc) which is lives only in the web server. David I see the difference between you plans as trade-offs between performance and scalability. "In memory" plan has better performance, "SQL plan" has better scalability - no significant performance degradation on growing number of simultaneous users. SQL also benefits from much higher critical failure protection. Should anything go wrong - it's much better to have the "stuff" in DB's transaction log than having it lost in RAM. Leonid Finis. > Could someone point me in the direction of good discussions on scalable > state management solutions? [quoted text clipped - 38 lines] > Question: is it possible to split a RAM state-server across multiple > machines? Hi John, we are using Strategy 1 here for a large web farm. In order to work-arround the SQL Session State performance issues, we are currently evaluating a product called ScaleOut StateServer (http://www.scaleoutsoftware.com/products/stateServer/index.html). Looks great so far! We also did Stratgey 3 but this can eventually flood the SQL Server with load. I do not believe that in the feature we will no longer have web farms (and therefor would be able to use normal ASP.NET inproc session state) because a single box will never give you the same availability as a farm (a mainframe maybe but then we're talking about a different league). And then there's the issues with maintenance and availability if you have only a single web server... Cheers Stefan > Could someone point me in the direction of good discussions on scalable > state management solutions? [quoted text clipped - 38 lines] > Question: is it possible to split a RAM state-server across multiple > machines? Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.