Performance note. WINS takes forever to configure: Hours pass
before the WINS server builds complete browser lists. After each system is
registered in the domain and given an IP address, you'll wait awhile before the
system is added to the list and made available in the Network Neighborhood
(although you can manually force access using the Run dialog: \\machinename).
You can try to force the WINS Manager to go out and scavenge for names, but this
action takes just about as long to rectify as waiting for it to happen on its
own. About the only way to speed this process is to configure a secondary WINS
server, which not only distributes the load for managing the names, but provides
fault tolerance if the primary server fails (which otherwise stops name access
from one computer to another on the network).
Multiple Cards
Extending network bandwidth in your server has some tradeoffs. Extra
overhead and I/O processing (e.g., interrupt handling) come into play when you
add cards. Each PCI NIC you add is another interrupt that the CPU must handle to
service I/O requests. More CPU interrupts mean slower processing.
Adding bandwidth increases the amount of information the system must
process. Additional bandwidth consumes extra resources such as memory and CPU
time--often requiring that you augment them to maintain your desired performance
level. As your system handles more data, you need to look at your disk subsystem
as the next potential I/O bottleneck.
All you can do is hope that putting the extra cards into your application
server doesn't slow it and negate the benefit you get by increasing network
throughput. You can help this problem somewhat by using full-duplex cards in
your servers and giving them direct connections to your fast Ethernet switches.
In our environment, we saw drastic improvements in performance by adding network
segments to the database servers under test, such as a quad-processor Pentium
Pro system going from a maximum of about 100 transactions per second to more
than 1800.
Wrapping Up
What you have in the end is a resource server, with a nice fat data pipe
into it and your users segmented into multiple logical networks to optimize I/O.
You can accomplish this functionality with 10Mbps hardware instead of 100Mbps,
but you will still want to use switched 100Mbps hardware for the backbone
(10Mbps hubs or switches with 100Mbps uplinks).
For example, if you have a SQL server that needs more network bandwidth,
you can segment your network, separating your users into discrete groups to
balance your load. Put one or more extra cards in your SQL server, assign them
the appropriate addresses (you don't have to use DHCP) to match your groupings,
add some switching or routing hardware, and away you go. Keep in mind the packet
collision considerations, and you have successfully increased your bandwidth.
Don't forget to download and install Service Pack 2 (SP2) for NT 4.0. This
update fixes several bugs in NT's networking components, such as duplicate
addresses from DHCP, IPX performance issues, and NetBIOS session conflicts. SP2
also adds the ability to handle BOOTP DHCP requests directly from the clients.
SP2 states that you must reapply it if you change or reload any network
services; otherwise, the system uses the wrong libraries from the NT
distribution CD-ROM. (For more information and some caveats about SP2, see
Jonathan J. Chau, "Service Pack 2," and Mark Minasi, "Recovering
from a Network Disaster," March 1997.)
See Also "Enterprise Testing Environment"
Register
