Performance Optimisation

The approaches taken to resolve performance issues largely depend on the application protocol in place although, from a generic networking perspective, there are a few potential issues that may affect the network performance between two sites irrespective of the deployment technology chosen.

Network latency The performance of terminal server based applications such as Citrix are most affected by network latency as the interaction between the user and the application is continuous and in real time.  Users are more likely to ‘see’ the lag affect of latency although latency will affect all applications, so we cannot just assume that web-browser clients will perform better over high-latency connections.  Latency may be inherent (in the ISP) where there are one, or many, congested points (routes) on the network that slow the round trip packet times between sites and cause the user to experience lag or slow screen refresh.  This obviously needs to be addressed at the provider level and we need to seek out the best options to reduce this to build a strong foundation for the network.

The critical issue is to ensure that the choice of ISP is carefully thought out based on the location(s).  Simple decisions like using the same provider in each continent can halve latency – but we should not blindly just use them everywhere if there are better options / exceptions in some regions. 

Increasing bandwidth does not reduce the inherent latency in the connection. It can reduce latency where this is caused by network congestion due to high levels of use.  Increasing bandwidth is more about application scalability; ‘adding extra lanes to the highway rather than increasing the speed-limit’. 

Network Design
There are myriad design factors that may affect network performance but generally we focus on a few critical areas:

1. VPN configuration and equipment; the quality of the VPN equipment / technology used can introduce overheads
2. bandwidth provision (at each site); as a guide, recommended bandwidth per terminal server / Citrix session is somewhere between 20-80k.  Generally we recommend at least 50k per concurrent RDP / Citrix session – this is not 50k per user but 50k per anticipated / average number of users that would connect at any one time.  It is not a scientific measure but a guideline.   Also note that the central location must be able to cater for the sum of all remote sites.  Remember bandwidth is capacity whereas latency is a measure of speed and most associated as a performance measure. 
3. compression and caching; historically with Citrix / RDP you do not get generally any further benefits of compression since these are highly compressed protocols although technologies are emerging to address this in the future.  Alternatively, with normal http / web and file transfer protocols you can get significant benefits by adding compression to the link.  So if the metric per browser user was 150k of bandwidth you could get that down below 50k using compression.  Caching can improve compression ratios where the file content does not change – e.g. DLL’s
• Note:   Compression appliances are generally required to be installed at both ends and need to be visible to each other – therefore a VPN is required or some form of ‘visibility’ between sites.

Disk based cache has a significant advantage to memory based cache for capacity / scalability and overall performance on larger deployments.

4. quality of service (QoS); any mission critical network protocol should be ‘shaped’ or prioritised to ensure guaranteed minimum bandwidth allocations.  This is one of the easiest and most effective solutions to apply for RDP / Citrix environments where the link is shared with other protocols such as email, http and ftp.
5. data location; referring back to choice of providers by location but also ‘Where really is the best place to host the application’.  If there are 5000 users in UK and 50 in Australia, then the UK may be the most logical place for the data-centre to maximise performance.