Ticket T164617
Visible to All Users
Duplicate

We have closed this ticket because another page addresses its subject:

XAF ASP.NET WebForms / Blazor UI deployment, scalability and load testing considerations

Sticky session auto scaling down work around idea (Web)

created 10 years ago

Hi DevExpress team.

Is it viable to modify the save action controller to initialise a new session when the action is clicked, I need my application to be able to scale down when my server load reduces. The idea is to make use of amazon instances with spot instance in high load situations, I will also be modifying the load balancer to have an affinity for the standard instance, and move the user off the spot instance when the save action is clicked.

  1. How resource intensive is the loading of the model and the security system?
  2. Is it possible to preserve the layout across the difference sessions and just reload?

Thanks in advance

Trentin

Answers approved by DevExpress Support

created 10 years ago

Hello Trentin,

Thank you for contacting us. We have not researched this particular customization, but I doubt it will be feasible without heavily modifying the XAF source code, because the current Web UI architecture is not designed for such a scenario. At the moment, an XAF Web application is supposed to use a single ASP.NET session, which is used to store service information (from the XafApplication, WebWindow and many others by means of the IValueManager interface, etc.) about the current application state. Starting a new session means creating and configuring an XafApplication instance from scratch and losing the connection to the previous session and thus the application state.
This setup process is quite resource-intensive, and we even use caching internally to avoid the loading of unchangeable parts of the application.

That said, I am not sure if you will be able to solve the original problem using the technical solution you described. I would be more than happy to learn more on this problem and circumstances that lead to that decision. For instance, how complex is your application? How many users are using it at the same time? What is the web server hardware spec? Feel free to provide any other information and schemas that can help better understand what causes problems at the moment.

    Comments (3)

      Hi Denis thanks for the prompt response.
      The current design makes use of  multiple m1.meduim amazon instances, each instance can support 35 con-current users before a new instance is required.
      Peak load when the system is fully implemented is a 1000+ con-current users, which will drop to 150 con-current users over night. This means we require about 30 instances during peak load and we only require 5 instances off peak.
      It is easy to scale up on amazon, however scaling down is not viable due to the sticky sessions. Thus the idea of initialising a new session each time the user clicks save, allow for the consolidation of users and then shutting down the under utilised servers.

      Essentially I'm looking for a way to seamlessly move users from one instance to another instance without getting them to logout and login again.
      There are tremendous cost saving to be had if we don't have to run the system at the high water mark and we can scale according to the load.
      If you require any more information please let me know.
      Thanks in advance
      Trentin

      Dennis Garavsky (DevExpress) 10 years ago

        Thank you for describing the original business problem you want to solve, Trentin.
        Like I said, with the current design of the XAF Web UI, I do not see an easy solution short of 1. remembering the logged state for a user (probably in cookies); 2. closing the current ASP.NET session after a successful save; 3. setting up a new WebApplication instance and automatically logging it to the user based on the remembered info, probably by using a custom authentication strategy. The steps 3 and 4 are the most problematic, because the setup process will require time as well as a sophisticated implementation of a custom authentication strategy. Take special note that I have not tested this instruction myself and we do not have ready examples or guidelines for this scenario. This is just my best advice based on my understanding of your situation, which I cannot guarantee will work in the end and which you can consider testing yourself, unless an ultimate solution is available in our framework.

          Thanks for the feedback, I will let you know how the idea pans out

          Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.

          Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.