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. |
"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. |
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. |
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.
5%
8%
