When we laid down the goals for 6.4, scalability was definitely one of the highlights alongside with customization it provides the ability to take Visual WebGui projects to the next level. At the base of Visual WebGui scalability, lays the ability to have the application state ported from one machine to another. This enables a non sticky scalability grid which with the addition of a state machines, also provide for redundancy.
So what were the challenges we faced?
The magic word is serialization, which is the corner stone of having the state portable. Now the serialization should be supper efficient as this is a process that will be added to every request. So what makes serialization fast? Ironically enough, the best tip for having a fast serialization is not doing serialization. So how do you use serialization without using it? Use it on the smallest amount of data and with minimum amount of graph junctions.
Facing the challenges?
The first thing we did was to start Visual WebGui on bytes diet and as I saw it at the beginning, Visual WebGui, has a lot of architectural advantages going for a successful diet. A Visual WebGui application state is actually a bunch of controls / components with properties. So let’s say we have 50 controls and 100 components, which in turn have 40 properties and 40 events in average.
This means that we have (100 + 50)*40 + (100 + 50)*40 = 12000 properties and events which are filled with data that we need to serialize, but after a short investigation 95% of those properties are default values which leaves us with 600 properties and events.
This led to the birth of the SerializableObject which is a serialization optimized container that has the ability to store data dynamically. So we can provide a default value and say if the container does not have a non default value return this value. So now we have 11400 properties less stored in the memory and the same amount of less data to serialize.
The only thing left is to flatten the graph to get the highest performance of the remaining data and that is also one of the abilities the SerialzableObject has built in. So now we have the default .NET serializer, serializing a small amount of flattened data, a couple of milliseconds which provide a very small price to pay for full redundancy.
So what does it mean for you as a developer?
The top most important thing to remember is that the application state is serialized so you will do smartly if you make sure that your state objects are serializable and low on byte calories. This means that you should use the SerializableObject capabilities in your custom control development to keep the state on its tight diet. You should use the serializable attribute on all your classes and structures and free resources as soon as possible to prevent non necessary data from being ported.
We will release in the near future a scalability ready analyzer tool that will enable you to see where you can make your application state porting as light as possible and some integrated Visual Studio macros / utilities that will do most of the dirty work for you.
How do you use it?
From version 6.4 preview 1 the scalability is integrated into the SDK so you can simply define a state server in the system.web configuration section and test it. By default we will provide it free for LGPL licensed projects with a waver and as a commercial license for non LGPL projects. This will enable developers to test and see how it fits before committing.