Supportworks Bandwidth Usage on the Network
| Status: | Published |
|---|---|
| Version: | 1.0 |
| Authors: | HTL QA |
| Applies to: | Supportworks ESP |
Supportworks Bandwidth Usage on the Network
This document examines the various factors that affect the performance of Supportworks client/server interaction in the context of Hornbill's proprietary Non-Polling Architecture.
Non-Polling Architecture (NPA)
One of the primary design goals for Supportworks was to be operable over slow-speed network connections, such as GSM mobile phones and the Internet. To meet this design requirement, a new approach to client/server operation was needed. Thus, Hornbill produced Supportworks Non-Polling Architecture (NPA), which addressed the inefficiencies of the conventional client/server model. Hornbill's product range still uses the same NPA design concepts today.
Unlike a conventional client/server application, Supportworks has its own application server that sits between the client(s) and the database server. ODBC/SQL connectivity to the SQL database is handled only by the Supportworks server and the clients connect only to the Supportworks server.
In this model, the Supportworks server acts as an arbitrator and uses a number of techniques to cache commonly accessed data. In addition to this, the Supportworks server keeps track of all changes made to the database and the data item(s) each client is displaying. In the event of a data item being changed (such as a new call appearing, a call escalation being flagged or a new e-mail message arriving), the Supportworks server notifies only the clients that need the information about the change. The client will then request only the changed information from the server. This substantially reduces network traffic during normal operation.
The term "non-polling" means exactly that. The Supportworks clients will never poll the server and will only request information from the server when the server notifies them of a change. The Supportworks application is so highly optimised that typically 80% of the activities that reference or affect data are cached in the Supportworks server's memory, thus substantially reducing the load on the underlying database server.
Typical Bandwidth Usage in a Standard "Out-of-the-Box" Configuration
It is quite difficult to estimate the amount of bandwidth that the application will utilise without having relatively accurate statistics on the number of open calls in existence, the number of records returned during searching, and the number and size of file attachments used. However, in the case of normal operational use, some estimates can be given for certain aspects of daily client usage.
The heaviest utilisation of bandwidth during normal operation will occur at login, when the server builds the client configuration data and the client downloads the current data dictionary. Typically, the act of logging in via the client will generate an overall data exchange of between 100K and 500K. Once this data has been loaded by the client, no further downloads are required during operation, as the client caches the data dictionary locally and this does not change unless the data dictionary has been modified and the client requires a newer version.
When the analyst selects the Service Desk (Helpdesk) view, its list of active calls is loaded into the call list display. The size of a typical call record will be of the order of 600 bytes.
Transactional functions, such as logging, updating, placing on hold, or closing calls, submit very little data: 0.2 to 2K on average. However, if file attachments are added, the size of the transaction can increase significantly.
If searches are carried out that return large result sets, this will use more bandwidth, which will be in proportion to the actual number of results returned.
Hornbill would recommend a minimum available bandwidth of 64 kbps for the application to remain responsive. Yet if ten users were connected via a 64 kbps link, any user logging a call would find the application just as responsive as if just one user were connected. This is due to the very small sizes of the record updates compared to the link bandwidth. If two users across this link happened to log a call at the same time, then they would be subject to twice the response time but, given the file sizes of call records, the double of a small amount may still be imperceptible.
A 0.5 Mbps connection is typically more than adequate for 10 analysts. This same bandwidth would be capable of servicing 50 users, but as the parallel transactions across the link increase, then so the responsiveness relative to the volume of transactions will decrease. If 50 users were experiencing good transactional responses and then one user carries out a very large search, returning 100,000 records, all the other 49 users would become unresponsive while the result set is pulled across the link.
During normal operational use, a 0.5 Mbps link would appear very responsive to 10 users, unless one of these users attempted to attach a 2MB file, in which case responsiveness would similarly suffer until the file attachment was sent or received.
It is fairly safe to assume that a 256 kbps link would be adequate for 10 users in typical circumstances. However, providing an additional 256 kbps to bring the bandwidth up to 0.5 Mbps would give a degree of headroom whenever large searches are conducted, or large files are attached.
Other Factors Affecting Responsiveness
Once a user is logged in, the bandwidth used will depend on user actions. For example, logging a call could conceivably transmit 100K, or even 100 MB+ of data at times, depending on file attachments, form configuration, the application template and customisation. Any lack of responsiveness stemming from usage factors is inherently intermittent.
However, bandwidth is usually not the issue that has the greatest impact on responsiveness. Network latency, for instance, has a more pervasive impact than bandwidth. Optimum system performance for LAN users requires that the latency should be less than 100ms. This value is dependent mainly on the network configuration.
We also need to consider the impact of a VPN connecting a client with the server. With a VPN in use, responsiveness will be affected firstly by the overhead consumed by the protocol encapsulation itself. Secondly, it will be affected by other client/server applications sharing the same bandwidth.
Finally, if some of the bandwidth on the network (VPN or otherwise) has been prioritised or set aside for a particular protocol, that would also have an effect on responsiveness.
Adapting Supportworks to Slower Networks
There are many ways in which Supportworks can be configured or tuned so that either less bandwidth is used or it runs acceptably on slower connections. For instance, limits can be set for attachment sizes, timeout values can be changed for several actions, custom searches can be disabled, configurations can be designed to make less use of the network and the Analyst Portal or Web Client can be used to perform the day-to-day logging and updating. Also, other infrastructure configurations such as terminal services (thin clients, Citrix, and so on) for your most remote analysts, can be considered.
Summary
As we have seen, typical usage patterns generally mean that transactions between the client and the server happen every now and again, and not all of the time. Bandwidth is not a single measurement one can use to determine exact performance: other factors such as latency, VPNs and protocol tunnelling can have a significant effect.
For example, suppose that a head office has a 10 Mbps connection to the Internet, a remote site has a 1 Mbps connection to the Internet, and a virtual private network (VPN) exists between them. If you pick the lowest bandwidth in the path (i.e. the 1 Mbps), you can still not rely on getting that because of the Internet itself introducing extra latency between the two sites. The VPN, too, will introduce its own overhead. Also, there is no guarantee that even the remaining bandwidth will be available to the VPN connection. In this scenario, a company would be using the same VPN connections for other services such as e-mail, file/print, and so on, so the available bandwidth at a given point in time would be entirely dependent on the activity of other applications and would therefore be even more unpredictable.
Supportworks has been designed to restrict its activity to small short bursts of network traffic to achieve the best possible performance in most network environments.