- 314 -
14.4.4 DNS Lookups
Looking up network addresses is an often overlooked cause of bad network performance. When your application tries to connect to a network address such as foo.bar.something.org e.g.,
downloading a web page from http:foo.bar.something.org
, your application first translates foo.bar.something.org into a four-byte network IP address such as 10.33.6.45. This is the actual
address that the network understands and uses for routing network packets. The way this translation works is that your system is configured with some seldom-used files that can specify this
translation, and a more frequently used Domain Name System DNS server that can dynamically provide you with the address from the given string. The DNS translation works as follows:
1. The machine running the application sends the text string of the hostname e.g., foo.bar.something.org to the DNS server.
2. The DNS server checks its cache to find an IP address corresponding to that hostname. If the server does not find an entry in the cache, it asks its own DNS server usually further up the
Internet domain-name hierarchy until ultimately the name is resolved. This may be by components of the name being resolved, e.g., first .org, then something.org, etc., each time
asking another machine as the search request is successively resolved. This resolved IP address is added to the DNS servers cache.
3. The IP address is returned to the original machine running the application. 4. The application uses the IP address to connect to the desired destination.
The address lookup does not need to be repeated once a connection is established, but any other connections within the same session of the application or in other sessions at the same time and
later need to repeat the lookup procedure to start another connection.
[4] [4]
A session can cache the IP address explicitly after the first lookup, but this needs to be done at the application level by holding on to the
InetAddress
object.
You can improve this situation by running a DNS server locally on the machine, or on a local server if the application uses a LAN. A DNS server can be run as a caching only server that resets its
cache each time the machine is rebooted. There would be little point in doing this if the machine used only one or two connections per hostname between successive reboots. For more frequent
connections, a local DNS server can provide a noticeable speedup to connections. nslookup is useful for investigating how a particular system does translations.
14.5 Performance Checklist
Some of these suggestions apply only after a bottleneck has been identified:
•
Tune the application before tuning the underlying system. This is especially pertinent to network communications.
o
Limit application bandwidth requirements to the network segment with the smallest bandwidth.
o
Consider network latencies when specifying feasible application response times.
o
Aim to minimize the number of network round trips necessary to satisfy an application request.
•
Constantly monitor the entire system with any monitoring tools available. Monitoring utilities include perfmeter Unix CPU, vmstat Unix CPU, RAM, and disks, iostat Unix
disks, performance monitor Windows CPU, RAM, and disks, netstat network IO, ping network latency and nslookup DNS lookup and routing.
o
Keep monitoring records to get a background usage pattern.
- 315 -
o
Use normal monitoring records to get an early warning of changes in the system usage patterns.
o
Watch for levels of paging that decrease system performance.
o
Watch for low CPU activity coupled with high disk activity and delayed responses. This may indicate an IO problem.
o
Monitor for retransmissions of data packets.
o
Ensure the CPU runnable queue does not get too large.
o
Aim for average CPU utilization to be not more than 75.
•
Consider spreading extra computation loads to low activity times.
o
Run offline work in off-peak hours only.
o
Time all processes and terminate any that exceed timeout thresholds.
•
Consider upgrading or reconfiguring parts of the system.
o
Doubling the CPU speed is usually better than doubling the number of CPUs.
o
Consider striping the disks e.g., RAID disks.
o
Add more swap space when there is no alternative way to increase the memory available to the application or to reduce the applications memory usage
requirements.
o
Test to see if running on raw partitions will be faster.
o
Look at mapping filesystems into memory for speedier startups and accesses. But be aware that this reduces system memory available to applications. For multiuser
applications, this is an efficient way of sharing in-memory data.
o
Move any components from network-mounted disks to local disks.
o
Ensure that system swap files are on different disks from any intensively used files.
o
Cluster files together at the disk level, if possible, or within one big container file.
o
Defragment disks regularly if applicable to your system.
o
Move executables or index files to disk sweet spots.
o
Consider altering priority levels of processes to tune the amount of CPU time they get.
o
Consider locking processes into memory so they do not get paged out.
o
Partition the system to allocate determinate resources to your application.
o
Consider tuning the maximum packet size specified by the TCPIP stack.
o
Ensure that your TCPIP stacks have no performance problems associated with them.
o
Consider running a local caching DNS server to improve the speed of hostname lookups.
15.1 Books
Kategori