Visual WebGui Performance

Server centric architecture is mostly examined performance wise by four major factors:

1. The amount of data sent and received from the client to the server and vice versa.
2. The intensively of which information transportation is required between the client and the server.
3. The server’s service capacity; in other words the count of users which can be intensively served (often called concurrent users) by one server.
4. The ability to leverage client machine’s power in order to increase responsiveness.

Visual WebGui attends those 4 major issues by design; a short reference of the architecture highlights which affect the 4 above:

1. Visual WebGui uniquely optimizes the protocol in a way that most of the requests and responses are less than 1kb.
2. The client is always the initiator of requests to the server as in standard web applications; the events mechanism is highly optimized and results in the minimal interaction on a server centric application run.
3. Having a full state of application on the server, Visual WebGui dramatically lowers the amount of construction and disposals of objects; this fact alone reduces the CPU usage dramatically and enables a single server to serve between 200-400 concurrent users.
4. Visual WebGui leverages the client’s power in order to render the UI, create a responsive and dynamic UI and perform client-client actions which do not require interaction with the server.

Visual WebGui Runtime Model

The following parts of the runtime model of Visual WebGui directly affect the runtime performance of Visual WebGui applications:

• UI Virtualization is performed by transferring highly optimized commands and events metadata from the client and from the server, for example, the following negotiation represents the scenario of clicking a button and as a result, opening a message-box with some text, 3 buttons (Yes, No, Cancel), a question icon and focus on the OK button:
  
  

  AJAX Request:

  - <ES LR="633704779264797648">
    <E SR="1" TP="GotFocus" />
    <E SR="1" TP="Click" X="43" Y="12" />
    </ES>

  The above request contains the absolutely minimal data required in order to update the server with what happened on the client:
  LR – Request identification including timestamp and internal data required for
  further optimization mechanisms.
  SR – Registered control Id.
  TP – event type → GotFocus – tells the server that the button got focus.
  TP – event type → Click – tells the server that the button was clicked on coordinates (43, 12).

  AJAX Response:

  <WG:R LR="633704779298387528" AF="10" FC="8" xmlns:WC="wgcontrols" mlns:WG="http://www.gizmox.com/webgui">
  - <WG:F Id="2">
  - <WG:F H="106" W="410" RD="1" TX="Confirm" TP="ModalWindow"
  FBS="3" FSP="2" WS="0" S="0" FCB="1" Id="10" F="1" PA="10">
   - <WC:TLP Id="6" TI="1" F="1" D="B" H="24" TX="">
                                 <TLC W="50%" />
                                 <TLC W="76px" />
                                 <TLC W="6px" />
                                 <TLC W="76px" />
                                 <TLC W="6px" />
                                 <TLC W="76px" />
                                 <TLC W="50%" />
                    <TLR H="24px" />
  <WC:B Id="9" E="1" RS="0" CS="5" RSP="1" CSP="1" TI="3" F="1" TX="Cancel" TA="MiddleCenter" TIR="0" L="0" T="0" H="23" W="75" A="LT" />
  <WC:B Id="8" E="1" RS="0" CS="3" RSP="1" CSP="1" TI="2" F="1" TX="No" TA="MiddleCenter" TIR="0" L="0" T="0" H="23" W="75" A="LT" />
  <WC:B Id="7" E="1" RS="0" CS="1" RSP="1" CSP="1" TI="1" F="1" TX="Yes" TA="MiddleCenter" TIR="0" L="0" T="0" H="23" W="75" A="LT" />
                     </WC:TLP>
  - <WC:P Id="5" TI="2" F="1" TX="" D="L" W="50">
  <WC:PBX Id="3" TI="-1" F="1" L="0" T="0" H="32" W="32" A="LT" IMS="0" IM="Skins.Question.GIF.wgx" />
    </WC:P>
             <WC:L Id="4" TI="3" F="1" SA="0" TX="Are you sure?" TA="TopLeft" D="F" />
            </WG:F>
                </WG:F>
            - <CMDS>
                         <IM MM="Controls_Focus" ARG0="8" />
                 </CMDS>
           </WG:R>

  The above response contains thorough instructions for the client kernel of what should be rendered as a result of clicking that button.
  
  In the above sample we may emphasize few important elements:

  • WG:F – Stands for “form“. It can be observed that the xml contains 2 forms – representing the main form and another open form inside (which is the message box form).
  • WC:TLP – Stands for table layout panel control which is a very important UI element which is responsible in this case to instruct the client to place a UI element which will create the reflected message-box layout.
  • WC:B – Stands for a button control with all of its non-default properties (such as text, location and size).
  • WC:PXB – Stands for a picture-box control containing the image (the actual picture resource will be grabbed through Visual WebGui’s resource management right after this response will be processed by the client kernel and then cached on the client)
  • CMDS – Stands for command which should be executed after rendering the UI, in this case the command is Control_Focus which will result in focusing the “No” button in this case.
  
  
  

  Any other UI state balancing option or virtualization would have transferred either a bit map or much less optimized state, this is exactly the reason why Visual WebGui is the undoubted winner in a comparison performed by Mr. Wiktor Zychla, Microsoft MVP and performance specialist (as shown bellow).

  

• Visual WebGui server holds the UI updated state at all times (up until disconnection); The state contains the currently relevant UI tree of controls, for example, if the screen currently shows a Form with a TreeView, a ListView and a few Buttons, the controls tree will look something like that:

  
  VWG Application Context
      Form (form-name, etc)
          TreeView (text, location etc)
              TreeNode1 (text, image etc)
              TreeNode2 -“-
                  TreeNode2_FirstChild
                   …
              ListView (location, text etc) o ListViewColumns Collection
                  ListViewColumn1 (text, width etc)
                  ListViewColumn1 (text, width etc)
                  …
              ListViewItems Collection
                  ListViewItem1
                      ListViewSubItem1 (text etc)
                      ListViewSubItem2 (text etc)
                      …
              Button1 (location, text etc)
              Button2 (location, text etc)
   

  Note: except for the controls tree, when developed correctly using all best practices of web development, there should not be allot more than that in the application context.

  As opposed to any stateless or semi stateless web applications such as ASP.NET, when the client sends events, the state already exists within the session as described above, and it is ready for executing any application logic on it. This fact dramatically reduces the amount of memory allocations, objects initializations, object disposals and garbage collector activity. This fact lowers the CPU usage accordingly.

  The fact that the CPU usage is very low directly reflects the capacity of the web server and its ability to fast serve all the requests. As shown in the graph below, compared to other AJAX frameworks and even plain JavaScript, Visual WebGui serves larger number of users faster (the comparison was performed by Mr. Wiktor Zychla, Microsoft MVP and performance specialist).

  

• Client behaviors and client-client actions are uniquely performed by the client:
  • Behaviors such as scrolling, state images and styles (such as hover) etc are handled uniquely by the client.
  • Critical events are those events that when they occur they should immediately be raised to the server; any non-critical event (majority of the events are non critical), are handled uniquely by the client in places where the developer did not choose to perform any logic in response. In order to keep the server state balanced, those events are queued and sent the next time any other event is raised to the server.
  • Unique events are queued only once, for example ListView selected index changed will be transferred to the server only once (the last selected index) even if the client changed his selection multiple times (unless the developer has chosen to handle this event on the server).
  • The option of performing client to client invocation enables the developer to apply application behaviors on the client without having to send them back to the server. For example, editing text in a RichTextEditor control, enables applying text styles (such as bold, italic and changing font) on the client side without raising events to the server and only the final result is transferred to the server. The optimizations above helps Visual WebGui leverage the client machine’s power and present a responsive and rich application.

Conclusion

Although Visual WebGui is a server centric architecture it optimizes the communication and the balance between client and server responsibilities, thus providing low latency and excellent performance. In highlights level, the following factors are producing this outcome:

• Low CPU usage on the server side low negotiation establishment time due to the existence of valid context at all times.
• Highly optimized communication protocol based on compressed deltas metadata and minimal commands.
• Leveraging the client machine power to minimize communication and throughput.  

 Next >>