Running thin clients is most often touted as a money saver. But in order to get optimal end-user performance, you may need to invest in server and network infrastructure. How much should you spend, and how can you make sure users are happy?

Agricultural giant Wesfarmers has gone thin in a big way. After years of relying on ancient dumb terminals to access aging information systems, the company's 200-site Industrial & Safety division recently installed more than 1600 Compaq T20 thin clients that employees use to access key information systems including Peoplesoft for human resources, Cognos for business reporting, and a company portal based on Plumtree software.

The applications Wesfarmers is using are typical of those used within many companies, but its intense reliance on thin-client computing illustrates just how far thin computing technology has come in the six or so years since philosophical debate about replacing Windows desktops reignited interest in the concept of server-based computing. Yet while the approach is technically sound, Wesfarmers--like many other companies--is finding the technical requirements for thin-client computing are more onerous than it originally thought.

"We're still sizing and developing our Citrix [MetaFrame] environment and the applications due to be rolled out this year," says David Whitaker, IT technical manager for Wesfarmers Industrial & Safety. "[It requires] more bandwidth across the network than we'd expected, in order to get the right sort of performance. We have [bandwidth] standards and fully expect we'll have to supplement them. But we're in the fortunate position that a lot of staff haven't had this facility before, so we can set and manage their expectations pretty early."

Increasing bandwidth requirements are particularly pointed in a company like Wesfarmers, where hundreds of simultaneous users and aggregated network traffic from 200 locations is putting the squeeze on existing wide area network (WAN) bandwidth.

The rolling upgrade of many Wesfarmers sites from ISDN to faster connections should relieve much of the problem, Whitaker says. Yet the reality of the company's thin client deployment echoes the experience at many companies, where increasing reliance on server-based computing is forcing businesses to revisit their technical infrastructure in an effort to eliminate bottlenecks and improve overall thin-client performance.

Rules of thumb--but whose thumb?
Now in use at more than 120,000 companies around the world, Citrix MetaFrame is far and away the world's most popular thin-client environment. When planning MetaFrame deployments, the company says, companies should follow the rule of thumb that one MetaFrame server will support approximately 30 users. The software's built-in clustering capabilities, the company repeatedly points out, make scalability a simple task.

In the users-per-server bragging war, however, it's Tarantella that takes the cake. Its Unix-based thin-client software can support nearly 2000 users per standard Intel-based Linux server, says Asia-Pacific regional sales manager David Luthje. "Where we really have strength is deploying over secure or very low-bandwidth lines, or to Web browsers," he explains. "They don't have to purchase hardware just to get access to larger apps."

If these sorts of estimates sound simplistic or overly optimistic, you're being duly sceptical. Despite the marketing hype, thin clients are definitely not a one-size-fits-all proposition--but vendor estimates rarely make reference to what speed of CPU would be necessary to support that number of users. It does matter, of course: it's unlikely that a single-processor 700MHz Intel Xeon server, for example, would support anywhere near the number of users of a modern dual-CPU 2.4GHz Xeon-based system.

In truth, the performance of thin-client environments depends not only on the number of servers in the farm, but also on factors such as the number of simultaneous users, the number and complexity of the applications running on the server, the bandwidth available between server and thin clients, and interference from other applications running across the network.

“Where Tarantella really has strength is deploying over secure or very low-bandwidth lines, or to Web browsers. They don’t have to purchase hardware just to get access to larger apps.” --David Luthje, AP regional sales manager, Tarantella.

All these contribute to a performance profile that's far less predictable than Citrix would have you believe. Different thin-client protocols perform differently over different types of connections, and benchmarking them has traditionally been quite difficult. Yet as companies continue to embrace the possibilities of thin-client computing, increasing usage of the technology is forcing them to pay careful attention to the amount and distribution of their network resources.

"For a SAP or Peoplesoft-type package, you can size it up pretty well," says Laurie Wong, business product manager for Sun StarOffice and desktops with Sun Microsystems. "Server tools provide feedback as to how things are going. But at the other end of the spectrum, graphics-intensive stuff, where users are resizing windows and running flashy graphics, require a lot more server grunt. As you move into deployment, there will have to be a tweaking and review of whether what's being delivered is adequate. It's a kind of round-trip engineering."

The trouble with benchmarks
During most application rollouts, companies test the performance of new systems by setting up pilot programs or staging the network in a test environment that simulates real-world application loads. This approach normally gives a good perspective as to what kind of load the corporate applications will put on the system--but when it comes to thin clients, the story is much different.

That's because conventional testing tools have had no way to monitor the actual thin-client user experience. Server monitoring tools--for example, Citrix Resource Manager or NTP Software System Sentinel--are typically installed on the server and provide a good picture of how well the server farm is serving up the applications. However, such tools typically provide little guidance as to what kind of performance they're delivering onto user screens across the country; performance problems are typically first heard of when users call the help desk to complain.

It's a critical issue: although thin-client solutions may scale nicely as a few dozen users are added, they can quickly run out of steam if available bandwidth is full or the application server is running at full capacity.

The need to assess end-user application performance has typically led to an even more rigorous evaluation period before thin-client systems are rolled out into production. Sun Microsystems, for example, offered integration partner Frontline Systems use of Sun's $2 million iForce Ready Centre staging facility during the design of the NSW TAB's 600-seat thin client deployment. TAB is using the SunRay thin clients as call centre support terminals, backed by Sun Enterprise E420R servers that help the facility handle over 22 million calls a year.

Although staging a thin client deployment can help demonstrate the right number of servers to use, it's an inherently deceptive measure of real-world performance: in a real deployment, performance is affected by issues such as network latency, fluctuating usage, and contention for server resources by other applications and administrative processes such as backups. Even rudimentary multimedia--Flash animations or low-bandwidth video--becomes a major problem for thin-client software that's doing all it can to squeeze a screen image down what is often a very slow connection.

This translates into variations in the performance of various thin-client technologies. For example, a recent analysis by PC Magazine Labs and Columbia University's Jason Nieh found a considerable difference between the efficiency of RDP (Remote Data Protocol, used in Microsoft Terminal Services), the RFB protocol of AT&T's Virtual Network Computing (VNC) thin-client software, and ICA (Independent Computing Architecture) used by Citrix MetaFrame. VNC ran on Linux, RDP, and ICA under Windows 2000.

“Citrix adds a fourth tier to a three-tier application. A lot of times, you roll out an app to users and people get concerned when they start to see performance degradation.” --Jonathan Rende, Marketing VP, Mercury.

During the transfer of a 63-second video file 23.74MB in size, RDP transmitted 117.93MB of data under Windows NT (the balance is largely control information), compared with 42.48MB of data in an ICA environment and 0.86MB for RFB (VNC, however, delivered unwatchable video so this number is not accurate). Running under Windows 2000, RDP pushed 30.38MB of data to the thin client, while ICA moved just 21.83MB and 1.19MB for RFB (which again failed to work). In these tests, the server was a 550MHz Pentium III based system while the thin client was running a 300MHz Pentium II chip.

Such studies reflect the large variations in the way that thin-client protocols handle data streams, although exactly what these differences are is not clear since the protocols' internal workings are not well documented. However, subtleties in thin client design confirm that not all thin client environments are created equal. It is clear, therefore, that using simple rules of thumb to provision server equipment can be painfully inaccurate. Conventional benchmarks do little to help, since they measure the speed at which the server runs the applications but cannot measure usability due to the protocols' dropping of packets to keep up over slow connections.

Recognising this problem, in February Nieh and several colleagues published their work developing what they call "slow-motion benchmarking", which they argue provides a far more accurate method of evaluating thin client deployments. In slow-motion benchmarking, network conversations between the thin client and server are captured while a conventional benchmark is run. Delays are inserted throughout the benchmark so that client-side screen refreshes have enough time to complete; in this way, the full output of the thin-client technology can be examined.

To assess the approach, the team tested RDP, RFB, ICA, and Sun's Sun Ray thin client technology running Web and multimedia applications, included in Ziff-Davis' i-Bench testing suite, over a variety of simulated link speeds made possible using Shunra Software's The Cloud. They used WildPackets' Etherpeek 4 network traffic monitor to watch the flow of data between client and server

When run at LAN speeds, all of the protocols delivered strong performance. But as bandwidth was gradually notched downwards, the results highlighted disparities in the way each protocol handled data. Sun Ray, for example, delivered slower page refreshes because its 24-bit colour support requires sending of more information than its competitors' 8-bit screens.

Overall, VNC and Sun Ray were faster at LAN bandwidth but ICA and RDP performed better at lower bandwidths--an important factor for those planning to use thin-client technology predominantly in-house. All protocols struggled to deliver what Nieh classified as "good" response times with 128Kbps of bandwidth. This issue becomes particularly pointed in situations where dialling in via modem, or eventually over a wireless GPRS, CDMA 1x, or 3G connection--a very real possibility as wireless-enabled devices gain enough momentum to be practical thin client terminals.

Tweaking the thin client
Mercury Interactive, whose application load testing tools have become crucial in general application design, took a different approach with last year's release of LoadRunner for Citrix, which allows customers to test thin-client applications' performance under load by sniffing out the ICA packets transferred between client and server.

"Moving to Web-based applications is a big undertaking, and Citrix is a very simple way for people to get applications out to their end users [quickly]," says Jonathan Rende, Mercury's vice president of marketing, explaining the customer demand that pushed Mercury into thin client testing. "But Citrix adds a fourth tier to a three-tier application, and before you know it a single transaction will go [for example] across the Citrix system, Siebel system, database, connected SAP system, and Web system. A lot of times, you roll out an app to users and people get concerned when they start to see performance degradation."

Thanks to Mercury's close partnership with Citrix, the company has been able to glean enough information about the workings of ICA that it can identify individual elements of the data stream. In theory, this makes it a far sight more accurate than conventional best-guess approaches to server provisioning.

LoadRunner scripts interact with MetaFrame screen images by waiting until specific bitmaps are displayed, then clicking on those areas. As in slow-motion benchmarking, LoadRunner scripts can be set to wait until a MetaFrame screen has fully displayed before the next action is entered; this produces results that are more true to the user experience.

This approach has proved to be a significant benefit for Motorola, which is using LoadRunner for Citrix in its Arizona, USA internal application testing facilities. "We really weren't in a position to do much with the load testing of Citrix," says Paul Benjamin, automated test manager within Motorola's Enterprise Shared Solutions division.

"The only way we could do performance testing was to try to run applications on the Citrix machine itself, but there was overhead associated with that. With this ICA support, Mercury has moved Citrix into the same category as ERP or Web testing: if you construct the test properly, you have a fighting chance of simulating reality."

“With this ICA support, Mercury has moved Citrix into the same category as ERP or Web testing: if you construct the test properly, you have a fighting chance of simulating reality.” --Paul Benjamin, Automated test manager, Enterprise Shared Solutions, Motorola.

Having that chance provides important guidance for companies wanting to make sure they've installed enough of the right kinds of servers to support their needs. But adding more servers isn't the be-all and end-all of thin-client scaling: organisations like AMES have used hardware quality of service-capable network switches to improve thin client performance, while a number of standalone applications improve performance by providing highly optimised caching of data between thin-client server and client.

These caches are built into existing protocols with the intention of eliminating the need for frequently-used data or screen elements to be continuously rebroadcast. RDP uses a 1.5MB RAM cache and 10MB disk cache for storing graphical objects, while ICA includes a 3MB cache and variable-sized disk cache.

In his studies, Columbia's Nieh found caching was not particularly effective in reducing bandwidth requirements--and even degraded the quality of video sent over the link. This effect is likely due to the processing overhead imposed by the caching algorithm, which would invariably waste time trying to pick out redundant elements from a video data stream where all the data is unique.

Improvements are more marked in conventional Web and application traffic, where redundancy is more common. But there are other ways of improving thin-client performance: veteran terminal vendor Wyse, for example, in January launched Expedian, a Windows Terminal Server add-on that seeks to improve server performance by keeping frequently-used application DLLs in memory so they don't have to be reloaded when many users are running the same applications.

"There is always a need on the customer's part to optimise performance," says John Truitt, senior product manager for software products with Wyse. "This approach gives you 30 to 40 percent more user capacity on a terminal server." Wyse also recently launched version 4 of its Rapport thin client management technology, which allows for software upgrades across a large fleet of hardware thin clients.

Similar improvements are promised through use of RTO Software's TScale, while Expand Networks recently claimed its ACCELERATOR Enterprise Caching Technology was improving ICA performance significantly in tests conducted with the Citrix Test Engineering Group. Those tests simulated the load from 4, 16, 32, and 48 users of Microsoft Office 2000, finding that the Expand technology delivered more than 461 percent speed improvement compared with uncompressed ICA, and from 230 percent improvement compared with Citrix's built-in compression.

Effective compression, combined with caching performance, can squeeze considerably more life out of a thin-client solution, reducing capital outlay costs for both servers and telecommunications links. This ability, in turn, improves the ROI equation for companies considering thin client deployments. Expand, for example, says its technology would allow 20 ICA users to be serviced by a single 64Kbps wide area network connection; the Citrix rule of thumb would normally limit this bandwidth to no more than two or three users. That translates directly into reduced network usage, which means better performance across bandwidth-constrained WAN and dial-up or wireless connections.

Years of experience working in thin-client environments have produced a number of methods to speed up performance. By staging deployments carefully and ensuring that applications don't put undue pressure on limited-bandwidth connections, it's more than possible to ensure thin clients truly deliver on their promise of faster application performance. With the right planning, thin, as they say, will be well and truly in.

Executive summary: thin clients on the fast track

• Ruling by thumb is a recipe for anarchy. Unless you're a tiny company with one or two dozen employees, you may well find your thin-client strategy requires more than one server. Be sure to test your configuration in a proving ground, and use testing tools to generate fictitious client loads that simulate many concurrent users.
• Bank on your cache. Caching is built into most thin-client software, and can provide a major speed boost by storing often-used screen elements on the remote device. But tests show it can also be a problem in situations where applications with little repeated information--video, for example--are being used. Performance will also vary depending on the size of the disk cache on the remote client. Configure your environment accordingly.
• Memory can be improved. Several third-party products use novel techniques to speed thin-client performance--for example, optimising memory utilisation on the server or caching application components so the same bits aren't loaded many times when users access the same applications. Look into these tools and see if they can't give your thin-client environment a boost.
• Good server performance doesn't mean users are happy. Don't be fooled by benchmarks showing that the thin-client servers are flinging out application sessions left, right, and centre. When bandwidth is low, thin-client software is designed to discard packets in order to keep up with the application running on the server. This means your users may be seeing jerky or strange images even when everything looks right on the server.
• Technicolor is for the movies. Some thin-client platforms support screens at full 24-bit, photorealistic colour, while others keep it to 8-bit colour. Minimising the number of colours and running at a lower resolution directly improve performance, since thin-client software doesn't have so much data to squeeze down the line.
• Be ready for cluster bombs. Aggregating many systems into server farms has become the most common way of scaling up thin client platforms. But make sure your failover procedures work properly: every once in a while, disconnect a few servers and see how much the user experience is impacted.
• Wireless WANs are still slow. Very slow. Although GPRS provides an always-on data connection, its performance characteristics are still being proven for corporate applications. Faster services such as CDMA 1x (from Telstra) and 3G (from Orange) have now hit the market, but higher costs mean it's important to weigh the real need for wireless thin-client access. A sparse client interface for data entry, or an enterprise application interface designed for mobility, may be a more cost-effective solution than trying to transmit full screen images into the field.
• Quality of Service can help. As with any traffic, it's possible to use hardware and software packet shaping products to dedicate a certain amount of bandwidth to your thin clients. This is particularly useful in branch offices, where general Web surfing and other traffic can cut into the bandwidth available for thin-client applications.
• Hardware still matters. Many vendors argue that old Pentium, Pentium II and Pentium III PCs can be repurposed into thin clients simply by wiping them clean and loading the right software. This may be, but thin clients are still computers with their own performance issues. If you're trying to extend the life of old systems, make sure their limitations don't translate into frustrated users.

Thin clients balance the books at Ligare
Getting a thin-client infrastructure right may be important for any company installing the technology, but the need for scalability becomes downright mission-critical when thin clients are the only way for employees to access key business systems.

Ligare, a Sydney-based private book manufacturer that produces the physical volumes on behalf of a variety of legal, educational, and technical publishers, found out the importance of this robustness when it recently upgraded its entire IT infrastructure to a Tarantella-based thin client system.

Chosen for its ability to dish up both Windows and Unix applications, Tarantella is running on a pair of Sun Microsystems 280R servers with a Sun D2 disk array, feeding Sun Ray thin client terminals installed on the desks of around 30 knowledge workers and throughout the company's discrete manufacturing workspaces. The company's primary business application is Oracle Manufacturing, and users are being served a GNOME desktop running Sun's StarOffice productivity suite.

The thin clients replaced what information systems manager Dominic McDonald calls an "ad hoc" IT strategy in the past that had grown erratically from a base of just three disconnected PCs a few years ago. By having a standard desktop throughout the company's three-building site, workers can get their own desktop screen by simply inserting a smartcard into any of the Sun Rays. Because applications are restricted to the central server, users' desktops are always preserved as works-in-progress--even during power outages that often arise when the company's 300-amp printing equipment fires up.

Choosing the right configuration of server was essential to make sure the thin client bet paid off, says McDonald. And despite vendors' claims that the software will scale far higher, he believes a new server would become necessary once the number of thin clients has grown past around 50. But in the meantime, he's confident the lack of bandwidth-intensive applications will ensure performance remains good for some time--particularly since the LAN supporting the applications has plenty of bandwidth available.

"The desktop is there for what their daily activity requires them to do--nothing more and nothing less," he says. "There aren't things on there where they can play around with the system and waste resources. But if we passed the 50 mark, I would have to get another server. It's really a case of the network is the computer."

QoS tool speeds thin client for AMES
While tinkering with cache settings and memory management can increase the number of thin clients a server is able to support, Adult Multicultural Education Services (AMES) has found another way to improve performance.

Spread across 20 sites in Melbourne and six in Sydney, AMES provides specialist multi-cultural language and employment services to more than a thousand students. Internet access was provided through the head office, with all branch-office traffic routed back to the central site over the company's wide area network (WAN).

Recognising that its distributed nature required it to economise usage of WAN bandwidth, several years ago AMES installed Citrix MetaFrame to allow delivery of other administrative applications, as well as the online learning tools it uses for student education, while keeping WAN consumption relatively low. Citrix was also used to provide remote access through dial-up connections.

During a recent installation of the Finance One administrative application, AMES realised the heavy usage of its thin-client and other applications was stressing its WAN lines, and it didn't want Finance One traffic to compromise the experience of its 1400 students and staff.

"Because we deliver online learning, there are competing demands in relation to Internet usage and Finance One," explains Tony Harding, IT manager with AMES. "There was contention between our employment service applications and Finance One, but we had to give priority to still other applications such as ResMan [AMES' link to the Department of Employment and Workplace Relations]."

With so many applications fighting for the company's bandwidth, AMES went to market and eventually decided packet shaping technology was the best way to control how much bandwidth was available to each type of application. Working with integrator Ipex ITG, it installed seven Packeteer PacketShaper devices, which monitor network traffic and limit the amount of capacity a particular application can use.

Once installed, the boxes provided significant insight into the type of traffic that was traversing AMES' network--much of it unexpected. RealPlayer, for example, was consuming up to 40 percent of the company's bandwidth, something that was reduced to one percent after appropriate policies were put in place. File sharing programs like KaZaA were banned, and some old systems transmitting the obsolete and noisy IPX protocol were upgraded to IP.

These improvements provided an immediate increase in available bandwidth, but that was only the start. AMES used the PacketShapers to set different qualities of service for each type of critical application--for example, around 40 percent of available bandwidth is reserved for high-priority administrative applications including MetaFrame and ResMan. The rest is left for use by Web surfing and online education.

"I'd say we've seen a 15 percent improvement in speed," Harding says. "By being able to prioritise, we can control the traffic flows between the remote sites and central hub as well as Internet usage. Download costs decreased, and we have more control over the performance of our WAN."

Subscribe now to Australian Technology & Business magazine.

Copyright © 2009 CBS Interactive, a CBS Company. All Rights Reserved.
ZDNET is a registered service mark of CBS Interactive. ZDNET Logo is a service mark of CBS Interactive.