| ★ wanayoo — archive 1999 http://data.com/Tutorials/WAN_Design.html | Nouvelle recherche | Portail wanayoo |
|
|
|
|
|
|
The client software executes the user application and requests data. The server digs into the database and extracts the information requested by the client--the number-crunching part of the process. Client and server communicate by exchanging SQL calls across the network, almost as though the network were serving as the system bus of a standalone machine.
The beauty of this approach is that it distributes the processing load between clients and servers, making it more flexible and scalable than conventional server-centric computing, in which the database server (typically a mainframe or Unix machine) does all the work and the clients are merely dumb terminals.
But from a networking perspective the picture isn't quite as pretty. Client-server conversations are as chatty as chi pmunks: A data request generates hundreds of small packets. Each of these is sent individually and acknowledged before the next packet is sent.
On the local area, this inefficiency is masked by the high speed and low latency of the LAN. Thus, end-users are likely to see quick response times. On the wide area, bandwidths are low--typically 56 kbit/s to 1.5 Mbit/s--and latencies much higher. And while net managers are likely to worry more about bandwidth, latency is the real killer.
Here's the problem: client-server SQL conversations over WANs are latency-bound. Network round-trip time--not bandwidth--controls how quickly the client can ask for more data. For example, a simple SQL data request can require 200 request-response cycles. If the average round-trip time per packet is 70 milliseconds, this request would take 14 seconds to complete--far too slow for interactive users.
Bear in mind that bandwidth is the signaling rate of the WAN circuit--the number of bits or bytes that can be sq ueezed into the pipe each second. In contrast, latency is the transmission delay of the network--the minimum amount of time it takes for any one of those bits or bytes to travel across the network.
Bandwidth and latency are related in a basic sense: Just getting the bits onto the wire takes longer at lower speeds--a phenomenon known as "insertion delay." But there are other sources of latency. Propagation delay, for instance, is caused by the length of the circuit: This unavoidable slowdown stems from the physics of transmission, including the speed of electrons on a wire or light waves in a fiber. For instance, a 5,000-kilometer circuit incurs at least 60 milliseconds of round-trip (propagation) delay, regardless of bandwidth.
Network devices like switches and routers also add processing delay as they shuttle packets among ports. They also can add queuing delay if they hold packets in buffers because outbound links are saturated or out of service. (Shared networks oft en have variable latency as a result of the extra queuing delays added during traffic peaks.) And it all adds up: Total network latency is the sum of the delay sources in the network. If it gets high enough, client-server apps will slow to a crawl.
So what's the answer? Use the lowest-latency WAN services available. In general, the more packet processing and queuing in the network, the greater the latency (see Figure 2). Leased lines exhibit low and predictable latency, which makes them a good bet for linking clients and servers. But they're also expensive, particularly when multiple sites need to be linked in a star configuration. Consider using leased lines for performance-critical sites, as a backbone technology, or for long-distance transmission.
|
Switched services like ISDN and switched 56 generally display latencies similar to those of leased lines. The question here is whether they offer enough bandwidth for a particular application.
Cell-switched services like ATM (asynchronous transfer mode) and SMDS (Switched Multimegabit Data Service) also should be considered. Since switching is handled in hardware, processing and queuing are kept to a minimum. Here again, the price may put these services out of reach of most net managers. When response time is absolutely critical, these high-speed services may be the best choice.
Packet-switched service like the Internet and frame relay may look like big bargains. But corporate networkers who use either for client-server communications may end up paying a performance penalty. Both involve more packet processing than the foregoing schemes, which translates into higher latencies.
In the real world, most net managers are going to have to choose between leased lines and packet-switched services. It's here that the differences are most apparent: A moderate-length (1,000 kilometers or less) 64-kbit/s leased line has a round-trip delay of roughly 25 to 40 milliseconds for small frames (100 bytes). The round-trip ride for the same-sized packets on a 64-kbit/s frame relay service is typically 35 to 90 milliseconds, with occasional spikes up into the hundreds of milliseconds.
A good way to determine the latency of a given network is to measure round-trip packet transmission time using a tool like the IP ping utility. This lets net managers know how long it takes to get a chunk of data across the network and back again.
Net managers looking to speed client-server communications can try a few other tricks. One is to move the clients and server closer together. This can be done by installing a database server on every LAN, reserving the WAN connections for applications that are less response-time dependent like e-mail.
This is good for larger remote sites. But it's also expensive. Another strategy is to shift the clients logically rather than physically by using communications servers or Web servers to tie remote users to the central site.
Here's how it works: Dedicated communication servers from Citrix Systems Inc. (Coral Springs, Fla.) and Cubix Corp. (Carson City, Nev.) and others let users create "remote control" PC sessions over a WAN link: The SQL client actually executes on the comm server. The remote PC sends only screen update information over the WAN (see Figure 3). Ironically, this brings net managers right back t o the bad old days of terminal-to-host connectivity. The remote PC is effectively reduced to a dumb terminal for database access (a huge waste of processing power). And net managers have to shell out for a second PC at the central site for every remote user.
Corporate networkers who want to make sure client-server apps don't bog down on the WAN should also consider using Web servers and browsers to access SQL databases. In this approach a Web server at the central site terminates the SQL stream and acts as a gateway for remote users. Unlike SQL, HTTP (hypertext transport protocol) is very efficient on the wire. Products from vendors like Netscape Communications Corp. (Mountain View, Calif.) and Oracle Corp. (Redwood Shores, Calif.) connect to database back-ends through product-specific proprietary interfaces or the standards-based (but slower) Common Gateway Interface (CGI).
Bear in mind that introducing a Web or comm server onto the network will increase costs and complexity, as well as add a point of failure. Still, net managers may be willing to make this trade-off to gain faster access to data. And as corporate intranets are rolled out, Web browsers and servers will become important options for database access.
|
Those philosophically minded folks in the MIS department can come in very handy when fine-tuning SQL application code for better performance ov er a WAN. There isn't much that can be done about the small packet sizes, but if the number of request-response cycles can be reduced, this may be enough to solve the performance problem. To ensure that MIS is doing this correctly, it helps to plug a protocol analyzer into the WAN to record and compare actual packet counts. Net managers also should bone up on the basics of network application efficiency (see The ABCs of Application Efficiency ).
SQL offers plenty of ways to minimize chatty behavior. Consider a typical database access: Each time the SQL app accesses a row from a table using commands like select, fetch, insert, and update, the server and client exchange a pair of packets. One way to minimize this is to tune the server's array size parameter, which determines the maximum number of database rows returned in a server's response packet. (The details depend on the particular SQL package and accessories.)
Another approach is using procedure language c ode constructs such as if/then and begin/end. For example, combining SQL statements within a begin/end block or within a stored procedure call may reduce dozens of packet cycles into one. It's also possible to combine multiple select statements into one statement specifying multiple tables as arguments. That way, the server can send data as one larger packet (rather than multiple packets), reducing the back-and-forth dialogue between client and server accordingly. Further, limiting the number of separate tables in a database--called "denormalizing the data"--can help cut packet cycles, but at the risk of creating other problems like reduced flexibility and more complex code.
Tuning SQL performance typically requires some organizational tuning as well. Often, SQL developers work in a different department from the folks with the analyzer. They may even be contractors. Net managers should seek ways to get everyone working together. It's particularly important for coders to understand why they're being as ked to consider these changes, since they're the ones most capable of optimizing the applications.
Net managers also should make sure they're running the latest revs of their network software--particularly since vendors are constantly upgrading their code to improve performance. For example, recent releases from Microsoft Corp. (Redmond, Wash.), Novell Inc. (Orem, Utah), and others boast local caching of network read requests.
Caching stores received blocks of server data in client cache (RAM or disk) so repeat requests can be locally serviced. Thus, traffic over the WAN is reduced. The bigger the cache, the better the chances of hits on repeat requests, and even smaller caches (1 Mbyte or less) can yield startling performance gains. It all depends on the application.
Some software also includes features like read-ahead caching. Here, the response to read requests includes neighboring blocks on the server's disk on the statistical assumption that they prob ably contain related information that the application may also need.
Upgraded LAN software also may improve burst performance by bundling multiple network-layer packets together and sending them as a group. While this can be very useful for some applications, it doesn't help cut down packet exchanges for client-server apps since these work at the application layer.
Despite the foregoing focus on tweaking and tuning applications, net managers still need to make sure their networks are in good shape. A badly tuned net clogged with extra traffic or plagued with transmission problems makes client-server performance--along with everything else--even worse.
Congestion is one factor that can affect client-server performance--especially on data links, where queuing delays can force packets to back up while waiting for outbound ports in switches and routers. This sort of congestion can occur on the WAN, when bursty traffic on lines between switches briefly exceed s capacity. It also can occur on the periphery of the WAN when shared-access lines become saturated with simultaneous user requests.
Mild congestion will cause packet delays. Severe congestion will result in dropped packets, forcing clients and servers to retransmit. Frame relay switches will dump packets exceeding the CIR first, which makes it critical to set the CIR high enough to ensure adequate performance in a congested network. When an expected packet is missing, the receiving station waits a few seconds before giving up and requesting a retransmission. Thus, as packet loss increases, performance plummets precipitously. Retransmissions are also caused by physical errors in the WAN, including bit errors on marginal lines and in defective equipment.
Frame relay and ATM offer traffic-policing mechanisms to prevent drops and retransmissions caused by congestion. But most LAN protocols will not respond to a signal from the network telling them to slow down. The only thing that tells them to t hrottle back is a dropped packet. This is analogous to stepping on the brakes in a car after an accident has occurred.
Once again, monitoring is key. If retransmissions are occurring on the WAN for any reason, that's the first thing to fix. The way to check this is by putting an analyzer on the network to see if packets are being junked. If they are, corporate networkers may need to add bandwidth to access lines or increase their CIRs. Another good idea is to check routers and FRADs (frame relay access devices) to see if they're dropping packets. If they are, their queues may be too small for the load. Also, check access lines to see if physical errors are contributing to drops.
Packet drops also can be a problem on carriers' frame relay networks. Carriers typically add frame relay capacity where and when needed, but localized, temporary congestion is possible as traffic on regional networks grows faster than expected. An uncongested carrier network is less likely to enforce CIRs--which means more bandwidth is available for user applications.
Maintenance protocols are another drain on WAN performance: The traffic generated by routing updates, service advertisements, name queries, SNMP management alerts, and the like can soak up a significant portion of available WAN bandwidth. Under extreme conditions, this extra load can cause applications to bog down.
Many maintenance streams rely on data link broadcasts to communicate. For that reason, bridging domains should never extend over a WAN. Instead, locate routers where busy LAN segments join the WAN. Also, avoid unroutable protocols like Netbios or filter them off the WAN. Alternatively, net managers can use DLSw (data link switching) to block Netbios broadcasts. On large Netbios networks, up to half the WAN bandwidth can be lost to explorer packets, even when there are no users on the net (see Token Ring Switches: Double Indemnity , June 1996).
Using link-state routing protocols over WANs eliminates periodic routing table updates and service name broadcasts. IP networks should use OSPF (Open Shortest Path First) or other efficient protocols, such as EIGRP (Enhanced Interior Gateway Routing Protocol). Netware networks should be upgraded to support NLSP (Novell Link Services Protocol) and NDS (Novell Directory Services). Routers also can be used to filter out Netware SAP (Service Advertising Protocol) updates, but eliminating these older broadcast protocols through upgrades is a better long-term strategy.
The foregoing helps keep the network in good shape, but net managers need to understand that their choice of protocols won't make client-server apps run any faster. No matter how data is sliced and diced, client-server SQL communications are equally slow over the WAN with TCP/IP, IPX/SPX, Netbios, and other protocols. Use the protocol stack that's best for users, but keep the talky protocols off the WAN.
Bu ying more powerful equipment won't help much either. Adding data compression or fancy queuing controls to routers may improve the performance of other LAN applications (and these features can prevent client-server performance from getting any worse when traffic streams compete for bandwidth), but they offer little performance improvement for latency-bound apps. Simply said, the packets are too small to benefit.
In the end, if net managers know that client-server is part of the WAN plan they need to go the extra mile to make sure performance is optimized before apps are rolled out. Developers need to be more aware of network efficiency when writing code. And networks need to be brought up to date with the latest products. With a little planning and tuning, and perhaps some new technology, the challenges of client-server communications can be met.
|
|||||||||||
|
|||||||||||
|
 |
|
|
