Performance/Scalability related issues

[anil]

Hi Oleg,

I appreciate your efforts on MVC# implementation across Windows/Web/RIA/Compact, while evaluating the framework from Web Application perspective I have noticed the following performance and scalability related issues:

1. View configuration is being created from scratch for each user session.
   Can we cache it and share across the user sessions / application, do you see any downside in doing so?

2. Storing the Task object in session
   Task object along with the configuration information is stored in Session, this would affect the scalability.
  Can we just store the Task object and associate the configuration information from the handler? Please provide your thoughts

Thanks
Anil

[OVZH]

Hi Anil,

1. This issue could be sovled by creating a caching IViewInfosProvider implementation. This implementation should return already created ViewInfosByTaskCollection instead of creating it from the start.

2. Please elaborate on this, what scalability problem do you mean? I'm not having much of web development experience, therefore any improvement suggestions here would be welcome.

Thanks,
--
Oleg Zhukov

[anil]

Hi Oleg,

Thanks for the quick turn around.

Item# 1 -  I am happy with the solution.

Item# 2 - I was refering to storing Task object with httpContext.Session.

    In addition to its  properties Task object points to the following collections too
         right?

        Navigator.TaskInfo
        ViewsManager.ViewInfoCollection

          As the size of the these collections depends on the size/configuration of the
          application, I am bit worried about storing    TaskInfo/ViewInfoCollection  along
          with Task object in session context.

    In a typical web application there can be huge number of users/modules,  so can we
         some how avoid storing Navigator.TaskInfo,ViewsManager.ViewInfoCollection  these
         objects in session ?

Thanks
Anil.

[OVZH]

Anil,

Ok, now I understand what you're talking about. Let me explain the state of things here:

With each task instance only pointers to the task and view information are stored. So having different tasks for each separate user session won't have a big memory footprint (and thus no impact on scalability). But...

... different MVCConfiguration instances do have own configuration data each. That is why to solve the scalability issue different user sessions should reuse the same MVCConfiguration object.

That is why instead of creating a new configuration on a session start:

        TasksManager tm = new TasksManager(WebformsViewsManager.
                                           GetDefaultConfig());

An already existing configuration (stored in some repository) should be used:

        TasksManager tm = new TasksManager(MVCConfigRepository.GetReusedConfigInstance());

By the way this would also solve the first performance issue.

Thanks for revealing these two issues! If any futher questions arise, write here or to the project feedback e-mail.
--
Oleg Zhukov

[anil]

Hi Oleg,

Thank you very much for your time. Sorry, I really missed out the point that sharing the config will resolve the issue mentioned in item#2

I would like to address one more issue with regard to scalability when an application is deployed in cluster environment.
We usually store the session state in sql server when an application is deployed in a cluster environment, as our MVCConfiguration  object is not serializable we may have to go for cluster nodes with sticky sessions to make it scalable.

I think we have to mark the following members in MVCConfiguration  as NonSerialized and make some changes to get methods of these properties to resolve this .

ViewInfosProviderType
TaskInfoProviderType
ViewsManagerType
ViewsAssembly

Hope you got the scenario....

Please let me know your thoughts....

Thanks
Anil.

[OVZH]

Anil,

I believe each cluster node should have its own cached copy of MVCConfiguration stored in a sticky session or application data. These configuration objects should be recreated for each node, or obtained from SQL server. In the latter case there should be means to store an MVCConfiguration object in SQL storage. Without modifying the code you may try to use some external serializer.

Hope it helps.

--
Oleg Zhukov

[anil]

Hi Oleg,

I do agree that each cluster node has got its own cached copy of MVCConfiguration, since we are caching the Task object in session, I am just wondering how we could route the session state to be stored in sql server or some other mechanism as the Task object doesn't support serialization as it refers to some non serializable types. 

Please let me know if need any clarification on this.... This would be a great framework if we could solve this....

Thanks
Anil.

[OVZH]

Amit,

I'm thinking of a roughly the following strategy in serializing tasks:

Implement a base serializable task class TaskBaseSerializable : TaskBase, ISerializable.

- During serialization it should store a) the name of the current view b) The dictionary of controllers for that task (could accessed via reflection on the Navigator.controllers member). Controllers in their turn should also be serializable.

- During unserizlization it should a) restore the name of the current view b) restore the controllers dictionary c) create new navigator and view manager instances, link them together and to the task d) assign ViewInfos and TaskInfo members of the created views manager and navigator to ones obtained from the MVCConfiguration (which is always in memory for the cluster node machine, as we discussed).

Does it solve major difficulties?

--
Oleg Zhukov

[anil]

Hi Oleg,

Yes, this is what exactly I had in mind...

Thanks again
Anil

[OVZH]

Sorry, I've misnamed you, Anil :)