Deployment Architecture and Considerations

In this article

    This document addresses deployment architecture and considerations for choosing different deployment scenarios depending of the number of users and the load they will impose on the system.  This includes small installations and installations using Network Load Balancing (NLB).  This document does not address splitting web and application servers onto separate machines.

    Examples, numbers and calculations described in this document are based on limited experience with SIX.web in a controlled lab environment.  Requirements for installations of SIX.web in different organizations with deferring usage patterns might deviate from recommendations outlined in this document.

    User

    One “normal” user of SuperOffice SIX.web is considered to be a person that uses SuperOffice CRM between meetings and other activities, and not 100% of the time.  A person using SuperOffice SIX.web continuously during the day should probably be considered as more than one user.

     

    If the organization is of a nature where all users typically use SIX.web intensively at the same time (e.g. when they arrive in the morning or after lunch) one needs to consider if the load they impose on the system is heavier than a “normal” user.

     

    Session State

    Session state is information on behalf of a user stored between requests from the web browser to the web server.  This session state can either be stored in the process belonging to the SIX.web application or outside this process.  ASP.NET Session Server is the recommended storage for storing this session state outside the SIX.web applications process.

     

    The session will be lost when the application domain recycles when the session state is kept inside the SIX.web applications process. 

     

    Storing session state outside the process of the SIX.web application imposes additional overhead.  This overhead is assumed to be < 25% of the processing cost.  Session state needs to be stored outside the SIX.web application process if session state needs to be shared between multiple web servers.

     

    Kernel

    A kernel is a CPU processing unit.  A dual or quad core processor contains 2 or 4 kernels.  Hyper-threading does not constitute a kernel.  Modern CPU’s are typically dual or quad processors and therefore have 2 or 4 kernels.

     

    Server

    This document assumes a server hold two dual core processors with a minimum of 3 GHz processor equivalent to Intel Xeon.  SCSI or SAS based disk architecture is recommended and IDE based disk architectures like SATA are discouraged for hard drives, CD-ROMs or floppy drives.  It is recommended that the server has enough memory so that swapping memory to disk can be kept to an absolute minimum.

     

    Web Server

    A web server should be a Windows 2003 Server with IIS 6.  The server should confirm to the requirements for Server defined above.  2-4 GB of memory should be adequate.

     

    Session Server

    A session server should be a Windows 2003 server with the ASP.NET Session Service running configured to accept requests from the different instances of SIX.web running.  2-4 GB of memory should be adequate.

     

    Database Server

    A database server should to a minimum confirm to the requirements of a Server.  It is recommended to have enough memory on the server so the entire database can reside in the servers’ memory.  SuperOffice SIX.web caches only a minimum of information for each user, as opposed to the 6.win client.  Hence; the load on the database server is significantly greater for SIX.web than it is for 6.win.

     

    IMAP services

    IMAP is the protocol used by SIX.web to read mail from the mail system.  The load on the IMAP service is significantly heavier than the one from a windows based IMAP client that caches all mail locally.

     

    SMTP services

    SMTP is the protocol used by SIX.web to send mail through the mail system.  The load on the SMTP services should be similar to the load a windows based mail client.