[DevExpress Support Team: CLONED FROM S36497: XAF ASP.NET Web Forms apps deployment considerations]
Me too:
3. Make it possible to serialize/deserialize session data of XAF ASP.NET applications (support the StateServer and SQLServer session state modes, AppFabric caching, etc.).
1 vote.
About scaling XAF ASP.NET applications
Answers approved by DevExpress Support
Hello Randy,
Please pardon my delayed response.
>>App is not leaking memory.
Thanks for your confirmation - that's great and I just wanted to make sure this is not the case in your app.
>>
Oddly in development if I dump GC.GetTotalMemory(false) I see 40-50mb fluctuation as I click the action button I have this hooked to. In our staging server, however, I see fluctuation of 30-200mb. Same code. Is there a better way to measure specific memory that my current session is using?
<<
Yes, there are much better ways, which you can learn more from public community resources like MSDN and StackOverFlow: http://stackoverflow.com/search?q=.net+determine+used+memory
For instance, even without specialized tools, you can consider using the standard System.Diagnostics.Process.GetCurrentProcess().WorkingSet64 / PeakWorkingSet64 APIs. It is important to note, however, that when measuring memory, it is also necessary to distinguish between the shared CLR memory used by other processes and private working set. There is a lot of information on Internet in this regard not to be confused in the end after such measurements.
>>It looks like every module and model item is stored in session.
Yes, it is. I elaborate more on this at S36497: XAF ASP.NET Web Forms apps deployment considerations.
>>Question: dumping out the Session.Keys I see WCCAspNetApplication in there 3 times. why?
This is a specificity of our design, which, however, should not increase the used memory in any way, because internally all elements of this dictionary should refer to the same single XafApplication instance.
Finishing with the memory, I want to emphasize one important thing to be considered. It is technically impossible to precisely predict the amount of used memory in a certain application also because this value may depend on the application data, implemented scenarios and even users activity. Imagine the following scenario: a user opened a DetailView and loaded a large picture (e.g., 30 MB) or a user navigates to a ListView with thousands of data records, but without using the server mode feature. This way, all this data will be kept in the session on the web server unless a user goes away from that View and GC decides to release unused memory. Since this situation may happen to many concurrent users at the same time, there may be moments when your web server normally requires a lot of memory even beyond the average value determined using the APIs above. I hope this makes sense as well.
>>
We've had some users complain that when they walk away from their computer for an extended length of time and come back they are unhappy they have been logged out. They would like more than an hour, however, the more liberal we get on this the more resources we need.
<<
As you probably know, by default we already automatically prolong the session (learn more…). This re-logon may also happen if the application pool was recycled, e.g. IIS decided to unload all running web sites after exceeding a certain memory threshold.
Let us know if I can answer other technical questions about our development tools that will help you make the right choice for your organization. Or, if you want, we can check your specific application locally and verify that its average memory usage is expected. In order to do this, we will require its debuggable source code, a database with test data and a description of typical user scenarios.
Hello Randy,
Would you please tell us more about your application specifics; e.g., planned usage scenarios, an approximate number of concurrent users, current issues, etc., because for now it is not quite clear why you think this proposed option will be suitable for you?
With that specific information we will be in a better position to describe the options available to you for the current version and also better track your business requirements for future product updates. Thanks for your collaboration.
Hi Dennis,
I guess right now we're not entirely sure if these scaling options will be suitable or not. Our current situation is we have built an XAF application that is hosted on a cloud VM serving 23 locations for a non-profit. We've already had to bump memory a couple of times (which increases monthly cost of hosting somewhat) because our estimates were a bit off. Currently, not counting abandoned/logged out sessions we're seeing pretty steady about 70-80 active sessions during peak times. This is causing about 80-90% total memory usage on average and some days memory pressure has caused stability issues when it goes over 90%. We have estimated their sessions are running between 40 and 50MB per session (more than the 10MB average you've stated). We run SQL Express and SSRS Express on the same server (again, non-profit so monthly costs are a constant concern). We know this client will be expanding soon (adding 3-4 centers in the next year) and so we are just exploring our options for scaling and not really sure what is the best approach (adding more memory, scaling out, SQL Session state, etc.) - Another issue with this client is they already complain about us having a 1 hour session timeout. Having sessions in SQL may allow us to more safely increase this setting. We know SQL Express 2014 will only address 1gb of memory so we understand performance could degrade under this option but it may be worth the trade off for better stability and increasing session time outs without having to constantly add more physical memory. However, without the option of doing this, we'll never know. Of course, other options may be creating an "IT bunker" with their own server(s) racked and co-located. Short term could be costly but long term may provide better options and be more cost effective. The current cloud provider is probably a bit pricey for them as well but other requirements (HIPAA & other privacy/security, SLAs, etc.) affected that decision vs. a cheaper hosting company.
Thank you for describing your situation in detail.
>>We have estimated their sessions are running between 40 and 50MB per session (more than the 10MB average you've stated).
These 10-15 megabytes are very approximate figures based on apps like our MainDemo. Of course, the exact numbers will vary based on the application complexity, e.g., the number of business classes, controllers, actions, etc.
It is also important to verify (with any memory profiler) that the app is not leaking memory due to problems in the custom code.
>>Another issue with this client is they already complain about us having a 1 hour session timeout.
Would you please clarify their expected results or how the app should have ideally behaved?
>>Having sessions in SQL may allow us to more safely increase this setting. We know SQL Express 2014 will only address 1gb of memory so we understand performance could degrade under this option but
Yes, this is a correct note about possible performance degradation due to the overhead cost on moving this stage back and forth.
For now, it seems that your best bet is to either increase available memory on your web server or think of separate servers for each client. Regardless, our team will take your business case into account for the future.
Hi Dennis,
App is not leaking memory. Oddly in development if I dump GC.GetTotalMemory(false) I see 40-50mb fluctuation as I click the action button I have this hooked to. In our staging server, however, I see fluctuation of 30-200mb. Same code. Is there a better way to measure specific memory that my current session is using?
I took a look at Session values in debugger and wow, yeah, there is lot of stuff. This app is not what I would consider large or complex either as far as number of persistent objects, etc. It looks like every module and model item is stored in session. I guess that's how it needs to be to be "stateful" It seems like most what we read was the number of users/sessions not scaling up well, but apparently the size of the application can also affect this.
Question: dumping out the Session.Keys I see WCCAspNetApplication in there 3 times. why?
WCCJ.Web.WCCJAspNetApplication
DevExpress.ExpressApp.Security.SecurityStrategyComplex
ModelApplication
DevExpress.Persistent.Validation.RuleSet
False
DevExpress.ExpressApp.ScriptRecorder.ScriptLogger
DevExpress.ExpressApp.ScriptRecorder.ControlNameHelper
Vertical
DevExpress.ExpressApp.Web.WebWindow
System.Collections.Generic.Dictionary`2[System.String,System.String]
WCCJ.Web.WCCJAspNetApplication
DevExpress.Persistent.Base.VisibleInReportsModelIndicator
WCCJ.Web.WCCJAspNetApplication
True
DevExpress.ExpressApp.PivotChart.ModelDimensionPropertyExtractor
We've had some users complain that when they walk away from their computer for an extended length of time and come back they are unhappy they have been logged out. They would like more than an hour, however, the more liberal we get on this the more resources we need.
Adding memory at this point is probably our only option as scaling out with their current hosting would be cost prohibitive… Problem is, we are expected to know how much is enough since they are going to be paying for it. So I guess it would be nice to know if 50-70mb is a good conservative estimate (which we figure would calculate to about $1 per user per month in memory allocation costs) - but it's hard to measure future usage since apparently it can increase just by adding more objects, controllers, etc. to the application.
Thanks,
Randy