bridge of the enterprise: Mission Critical Desktop Performance
Achieving acceptable desktop performance in a mission-critical client/server environment is no small task. It is difficult enough when your environment is simply a LAN, but add the complexities of a WAN or, even worse, an international WAN and you have the whole straw and camel scenario.
First, let's define the type of application I am discussing. These are interactive applications that, by mission-critical definition, if they are down or too slow, your company ceases to do business. These are typically record-level type apps like order entry, A/R and so on.
Client/server technologies, graphical interfaces and open systems have not been kind to these applications. The better architectures are written to major database engines like DB2, Oracle, etc., and are best written in variants of C in a two- or three-tier deployment. No, Access does not count. I am discussing large-scale implementations here.
The problem is that most of these implementations are written to be open and portable, therefore SQL calls through ODBC connections are the norm. This means the number of SQL turns -- SQL statements sent, data returned -- to get just a few records can be significant. Add a couple hundred users doing this and a high-performance LAN will take a serious hit. Add a couple hundred users over a WAN with or without significant latency issues, and performance dies.
Many different approaches have been tried in an effort to overcome this problem, each with its own level of success.
One of the first attempts is to add multiple tiers to the mix. Instead of having one database server and a bunch of clients running all applications, applications servers are added. Then additional database and applications servers are added. These all help. Workgroup servers, placing more static data closer to the users in a WAN, help reduce turns over the WAN but data replication traffic increases so the net result is not as good as you may initially think. All of these tactics produce results, but they rarely produce the desired response times.
Windows Terminal Server Edition is a great help in the ever-growing desire to achieve better response over the WAN. Using TSE, you eliminate the SQL turns over the WAN and can limit them to a confined LAN segment for performance. The only traffic over the WAN then becomes screens, characters and mouse movements. Add Citrix Metaframe, and Windows TSE really catches fire. Citrix adds better screen management and local print capabilities, it enables the use of local drives and devices, and enables cut and paste. The combination of TSE and Citrix can produce WAN traffic reductions of 80 percent! This comes, of course, with a price. The price, however, can be significantly lower, both in the cost of fatter clients and more bandwidth than the traditional deployment.
Internet technologies will probably provide the solution we need. Both HTML and Java show great promise, though Java is still a little slow. A combination of Java applets and servlets combined with some C on application and even database servers looks like it may be the answer to all the problems currently associated with large-scale client/server deployments. Traffic is down, application management is greatly simplified, licensing is simpler and it all looks familiar to most users. Most major players in applications software are either diligently working on this solution or have it on the drawing board. Those that don't probably have not gone through the pains associated with any real WAN deployments. Rest assured, they will find out.
Most likely, as we get closer to real large-scale deployments using these newer methodologies, we will find holes that need to be filled, and eventually even better ways. But isn't that what evolution is all about?
A veteran of the IBM midrange arena since 1983, Chris Gloede is executive VP for Business Solutions Group in Wayne, Pa. cgloede@thebsg.com.