Executive summary: thin clients on the fast track
Thin clients may work wonderfully, but they're hardly set-and-forget technology. Here are a few things to remember to make sure you're getting the most from your thin-client infrastructure:- 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.
4%
4%
