Sharing a Party Line

Another key factor is how fast all the bits and pieces of your infrastructure can talk to one another. To illustrate, a typical scenario might run as follows:

With all of this internal chit-chat going on, it should be obvious that significant bottlenecks can exist at any level. Yet, I'm always surprised at how rarely this possibility is ever given serious consideration.

There is still an awful lot of hardware out there that's running on 10Mbps network interface cards (NICs). Somehow, administrators rationalize their reluctance to upgrade by telling themselves that the older cards are "plenty fast" for what they want to do. But when it comes to your servers' internal network, total speed isn't the only concern. Even if the throughput is fast enough, the latency of slower cards could still kill you. Upgrading to 100Mbps or even Gigabit Ethernet can make considerable difference.

In many cases, you see all of those entities connected by a simple Ethernet hub, especially when they live in the same tier. There are a few problems with this approach. First, it limits the performance of the entire Ethernet segment to that of the slowest device. Often, if you plug in a 10Mbps device, it will force the other devices to drop down to 10Mbps as well. It usually causes these devices to run in half duplex mode, even if the remaining hardware supports faster speeds. In addition, network collisions, which can occur when packets are sent at the same time by different devices, become a significant issue in such a shared environment, and can seriously degrade performance.

Instead, installing network switches in favor of "dumb" hubs makes supreme sense. In very simplistic terms, switches place each connected device on its own Ethernet segment, so that all devices can run and operate at top performance and efficiency. This means that one device can run in 100Mbps, full-duplex mode, for example, even if other devices cannot. Instead of all devices (Web servers, application servers, storage devices, and so on) listening in on a single party line, the switch ensures that packets are directed (or switched) to only those devices for which they're meant.

An added bonus is that switches allow dedicated communication between devices. For example, let's assume we have four devices, two with 10Mbps interfaces (A and B), and two with 100Mbps interfaces (C and D). With each device on its own switched segment, A can talk directly to B at 10Mbps without impacting the 100Mbps communication between C and D.

Turbines to Speed

When I need to tweak a system to squeeze as much performance out of it as possible, I envision myself traveling along the paths that each request or response must traverse on its journey. It's at this low level that I sometimes discover bottlenecks or areas for enhancement that I wouldn't normally see when looking at the problem from a more general, infrastructure perspective.

We didn't look at, for example, the performance of the actual TCP/IP networking stack running on the server itself. This performance can vary widely depending on the operating system. If you have the luxury of designing your server environment from the ground up, taking the time to investigate which operating system is right for your Web and application servers makes a lot of sense.

Also, sometimes it's easy to forget that the upstream connectivity provider you choose can affect your overall performance significantly. To improve performance, you can select a provider that also handles your major clients' or customers' traffic. In this way, you can avoid the performance hits that come from jumping your traffic from one network backbone to another.

Ultimately, however, remember that real performance is measured by your users' overall experience, not simply in the details of your architecture. Your clients, your customers, and your business partners will decide whether your site is slow or fast, and that's where the rubber truly meets the road.

Postscript

As you may know, this is the last issue of Web Techniques before it reappears next month as New Architect. This will also be the last installment of my "At Your Server" column for the magazine. I would like to say that it has been a real privilege to have been afforded this forum, and I hope you have found at least some nuggets of useful data in my articles. I have greatly appreciated all of your feedback.


Jim has been active on the Net since the '80s. Best known as one of the core developers of Apache, and a member of the board of the ASF, Jim helps out as a senior consultant for Covalent Technologies. You can reach him at jim@jaguNET.com.