Network Components

Network Components

Let's start our review of the web site with the most underappreciated component: the network. The network acts as the arteries and veins of your web site. Every request entering your site moves across the network, as does every outbound response. In between, the HTTP servers, application servers, databases, content servers, and the like all depend on the network when sharing essential data required to handle the incoming requests . If something in the network hampers this flow of information, the web site does not work at peak efficiency.

Despite its essential function, the network plays an invisible role at the web site. Unlike noting problems with the servers, detecting an overworked network is not as easy as glancing at a CPU monitor. Many web site teams lack the skills for monitoring network performance or even for determining the network capacity their web site requires. For these reasons, network problems often go undetected until they become critical. This section covers some of the basic components of your network and their function. We suggest you also consult Chapter 9 for more details on network capacity planning and troubleshooting.

Routers

Routers connect your enterprise to the Internet, so they usually mark the start of your web site's network, as shown in Figure 3.1. When you select a router for your network, make sure it's rated to handle the full bandwidth of your upstream link to the Internet. Also, check the router's settings to ensure it's properly configured for your anticipated network traffic. Routers impact performance when they limit the network's potential bandwidth. Typical symptoms of a router problem include low network utilization and low machine utilization. If the router becomes a bottleneck, traffic simply does not reach the network and the servers attached to the network.

Figure 3.1. Router placement in a large web site

If you observe these symptoms in your environment, monitor your router. High CPU utilization at the router usually means you need a larger unit. Also, improper configuration may prevent the router from performing at capacity. Sometimes it's not possible to monitor the router. In these situations, try moving your test clients so the router no longer lies between them and the servers under test. This technique eliminates the router from the test, and tells you if the router contributes to performance problems.

Firewalls

Usually, a firewall follows immediately behind the router in your web site's network. Firewalls prevent unauthorized network traffic from flowing between the external world and the enterprise. A typical installation adds a second firewall or set of firewalls between the servers and the enterprise's intranet. This configuration supplies an extra level of security in case of a hacker attack from the Internet against one of the server machines.

Figure 3.2 illustrates a typical network topology. The network segment between the two firewalls is known as the DMZ. (See the discussion on firewall usage later in this chapter in the section entitled Web Site Topologies for more details on firewall configuration.)

Figure 3.2. A typical web site firewall configuration

Much like routers, undersized or poorly configured firewalls act as bottlenecks in the network. The symptoms of a firewall problem resemble those of a router problem: poor network and server machine utilization. Sometimes firewall problems also result in refused connections at the browser/test driver, or dropped connections between the application server and the database. We recommend initially testing without firewalls in your environment. After obtaining a baseline of performance, add the firewalls to your configuration to gauge their impact on overall web site performance.

Proxy Servers

Proxy servers and reverse proxy servers commonly reside in the DMZ. Proxy servers hide the network addresses of machines configured to route traffic through them. Enterprises use regular proxy servers for outbound traffic, and these machines seldom impact web site performance. Reverse proxy servers, however, often act as security devices for funneling inbound traffic through the second firewall in a DMZ. (Figure 3.3 shows such a configuration.) Since the reverse proxy funnels all the traffic in this web site, it easily becomes a bottleneck if improperly configured.

Figure 3.3. Reverse proxy server used for security

Another common reverse proxy server configuration places it at the front of the network to cache content closer to the user . Figure 3.4 shows such a typical reverse proxy setup. In this configuration, the reverse proxy server caches the web site's static content (static HTML pages, jpegs, gifs, JavaScript, and so on). This produces several advantages for the web site.

• The reverse proxy server quickly responds to browser requests for static elements without passing the requests further into the web site for handling. This reduces the path length of the static requests and results in faster performance for the user. (Most web sites receive far more requests for static content than for dynamic.)

• This reduces the burden on the other portions of the web site. The HTTP servers and web application servers no longer handle the bulk of static requests (the reverse proxy server handles them instead). This gives the web site more bandwidth to handle requests for dynamic pages and decreases overall network and server load further into the web site.

Figure 3.4. Caching reverse proxy servers

Some application servers also support pushing some dynamic content into the reverse proxy server. For example, a news web site might cache the site's "front page," since every visitor accesses this page. Whenever the page changes, the updated page replaces the original in the cache. This technique works well for dynamic pages that are accessed frequently but updated relatively infrequently. High-volume web sites serving lots of static content find reverse proxy servers particularly useful. In particular, e-Commerce web sites frequently use this configuration to support the gifs and jpegs embedded in their catalog pages.

Under the covers, a proxy server is just a highly specialized HTTP server. Many of the performance tips in the HTTP server section of this chapter also apply to the proxy server. In general, make sure your reverse proxy server supports the incoming traffic loads you anticipate. (Consider adding reverse proxy servers to support very large web sites.) Also, make sure you configure the reverse proxy with enough listeners to support the incoming traffic. Finally, the reverse proxy server needs enough capacity for its cache of static elements. As you add applications (or modify existing ones), check the impact of the new or updated pages and their static content on the proxy server. Note that the proxy server may require more network bandwidth than the portions of the web site returning dynamic content. (Graphic elements require more network bandwidth than HTML text because they're simply larger.)

As with the router, we suggest beginning initial performance testing without the reverse proxy server. Add it to the configuration after obtaining some baseline performance measurements. This gives you a reference point to determine the impact (if any) of the reverse proxy on overall performance.

Network Interface Cards (NICs)

Web site servers often use multiple network interface cards (NICs) to increase network throughput and decrease congestion. Keep in mind that web traffic is not balanced: The size of a request is usually many times smaller than the response. For this reason, web sites sometimes route incoming requests over a normal network while sending the outbound responses over a high-speed network. (Figure 3.5 shows such a topology.) Machines bridging the inbound and outbound traffic require two NIC cards, one for each network, in these topologies. Beyond the inbound and outbound request traffic, the web site sometimes uses multiple networks to support the site's DMZ or to separate web application traffic from database traffic. In all these cases, any machine bridging the networks requires multiple NICs.

Figure 3.5. Different speeds for networks handling different loads

NICs sometimes impact performance, especially that of systems using multiple NIC configurations. In many operating systems, the system administrator binds processes to particular NICs. Misconfigured bindings sometimes cause overloaded NICs, resulting in performance problems or application failures. To make matters worse , the NICs themselves vary in complexity and operation. For example, we once encountered a particularly difficult error involving improperly configured programmable NICs. (In this case, two machines contained cards with duplicate MAC addresses, and one NIC failed whenever the other started.) Likewise, we've encountered NIC cards with buffering or pacing algorithms, which interfere with the machine's network throughput.

Even simple NIC configurations sometime impact performance. An overburdened NIC card acts as a bottleneck. If the overburden card resides in a firewall server or HTTP server, it prevents traffic from reaching many other web site components. Test client machines frequently experience NIC overloads. The test client tries to simulate the activity of many users all on a single machine. If the web site returns large pages, or if the test client tries to simulate a large number of concurrent users, the resulting traffic volume frequently swamps the NIC.

Network card problems prove incredibly difficult to diagnose and resolve. Many operating systems fail to provide any useful monitors for attached NICs, and CPU activity does not always act as an effective gauge of network activity. Hands down, a network protocol analyzer is the best tool for finding NIC problems. If you don't have a network protocol analyzer, or you can't use one on the network in question, try isolating or removing web site components until you find the machine causing the problem. Finally, avoid simple NIC errors. If you upgrade the network from 10Mbps Ethernet to 100Mbps, make sure the attaching NIC cards support 100Mbps.