Network Performance Guidelines
The application has a potential to adversely affect the network primarily through large data transfers broadcast and multicast transmissions.
Data Transfer Limit
The current workable limit for large data transfers over WANs is approx. 1 minute equal to approx. 25 Mbytes.
The application's performance over the network is primarily depending on:
- Network latency (built-in delay caused by distance and components)
- Number of frames involved in each transaction
- Extent to which individual frames in a transaction require acknowledgement before the next frame can be transmitted.
There are certain application characteristics that may work acceptably well on a local machine, but when run across a network can cause a marked effect on performance and resource consumption. The following behaviors should be avoided:
- Chatty Applications. Some applications perform many small transactions. When combined with the network overhead for each of these transactions, the effect is multiplied. In networking, small transactions can consume as much resources and time as large transactions. The remedy: combine many transactions into a single large transaction.
- Serialized Transactions. Unnecessary serialization of transactions can degrade performance and affect the scalability of the server for those applications. For example, 1,000 serialized transactions would take at least 1,000 * RTT to complete. To solve this dilemma, you can run unrelated transactions in parallel. Serialized applications combined with chatty applications can cause very slow response. Because properly de-serializing an application can be difficult, consider combining transactions into larger transactions instead.
- Fat Transactions. Applications that send unnecessary bytes on the network are considered fat applications. This increases network overhead and slows performance. Usually this comes from inefficient data structures or inefficient data streaming. You should optimize your data structures or consider using compression to eliminate this problem.
Recognizing Slow Applications
- Connect-Heavy Applications. Some applications instantiate a new TCP connection for each transaction. Connection establishment takes time, contributes extra RTTs, and is subject to slow-start. In addition, the closed connections are subject to TIME-WAIT, using up precious system resources.
- Large Number of Simultaneous Connections. The number of concurrent connections an application uses should not exceed two, except for special purpose applications. Exceeding this can result in wasted resources. A good guideline is to have up to four short-lived connections or two persistent connections per destination.
Best Practices for Interactive Applications
- A ?slow? application exhibits one or more of the following symptoms: Low CPU and network utilization?the computer appears to be waiting on something. There is a good chance that it?s waiting on the network.
- Turning off the Nagle algorithm through the TCP_NODELAY socket option speeds things up. Because this also increases the protocol overhead, don?t use it to fix broken applications!
- The application exhibits high overhead. To calculate your application?s overhead, determine how much data you intended to transfer in each direction. Then use netstat and add (for Ethernet) 60 bytes for each packet and 500 bytes for each connection. The best overhead that can be expected for streaming over Ethernet is approximately 6 percent. For a modem connection, the best overhead is approximately 2 percent because PPP link uses header compression.
- Application response slows when the connection has a large RTT. Assuming your application is not approaching the link?s bandwidth, a large RTT should have little or no effect. A dramatic slowdown with a large RTT is a clear sign of serialized processing and many small transactions.
- The essential thing to remember is to test your application in an environment with a large RTT, a safeguard that uncovers most slow applications. This testing could be done in several environments, including a wireless LAN network, a link delay simulator, or satellite network.
Here are some general strategies to apply when writing applications:
- Make the data blocks as large as possible.
- Use a few large transactions instead of many small ones. Large transactions can also be efficiently streamed.
- Treat the network as a slow, unreliable resource. An application should minimize its reliance on the network.
- Use a well-architected representation of the data on the network. The data representation should be computer architecture agnostic, contain no fat, and possibly be compressed.
- Architect your applications so that they do not mix infrequently required data with frequently required data and provide just the necessary data.
- During initialization and shutdown, don?t make the user wait for the network to startup or shutdown. Network related initialization could take a relatively long time. Separate the non-critical network code.
- Address significant errors that actually affect the integrity or performance of the application; not all errors are critical. Implement recovery mechanisms and provide non-intrusive user feedback.
- Use Remote Procedure Calls (RPC) only when appropriate. RPC is synchronous on Windows 9x platforms and always results in chatty, fat protocols when used to send small amounts of data.
- Measure your network overhead, you may be surprised!
And do the following when testing an application:
- Test the application on all possible network varieties. Spend sufficient time understanding how the application behaves on the slowest or least stable link.
- Have Network specialist profile your application's network activity as part of your testing.