Web Performance Tuning: Speeding up the Web

Overview

As long as there's been a Web, people have been trying to make it faster. The maturation of the Web has meant more users, more data, more features, and consequently longer waits on the Web. Improved performance has become a critical factor in determining the usability of the Web in general and of individual sites in particular.

Web Performance Tuning, 2nd Edition is about getting the best possible performance from the Web. This book isn't just about tuning web server software; ...

See more details below
Paperback (Second Edition)
$34.15
BN.com price
(Save 24%)$44.95 List Price
Other sellers (Paperback)
  • All (18) from $1.99   
  • New (8) from $5.94   
  • Used (10) from $1.99   
Sending request ...

Overview

As long as there's been a Web, people have been trying to make it faster. The maturation of the Web has meant more users, more data, more features, and consequently longer waits on the Web. Improved performance has become a critical factor in determining the usability of the Web in general and of individual sites in particular.

Web Performance Tuning, 2nd Edition is about getting the best possible performance from the Web. This book isn't just about tuning web server software; it's also about streamlining web content, getting optimal performance from a browser, tuning both client and server hardware, and maximizing the capacity of the network itself.

Web Performance Tuning hits the ground running, giving concrete advice for quick results — the "blunt instruments" for improving crippled performance right away. The book then shifts gears to give a conceptual background of the principles of computing performance. The latter half of the book examines each element of a web transaction — from client to network to server — to find the weak links in the chain and show how to strengthen them.

In this second edition, the book has been significantly expanded to include:

  • New chapters on Web site architecture, security, reliability, and their impact on performance
  • Detailed discussion of scalability of Java on multi-processor servers
  • Perl scripts for writing web performance spiders that handle logins, cookies, SSL, and more
  • Detailed instructions on how to use Perl DBI and the open source program gnuplot to generate performance graphs on the fly
  • Coverage of rstat, a Unix-based open source utility for gathering performance statistics remotely

In addition, the book includes many more examples and graphs of real-world performance problems and their solutions, and has been updated for Java 2.

This book is for anyone who has waited too long for a web page to display, or watched the servers they manage slow to a crawl. It's about making the Web more usable for everyone.

This handbook is for anyone responsible for a Web site, from the person running a personal site off a Linux PC at home up to large corporate site managers who wants to improve their performance right now.

Read More Show Less

Editorial Reviews

From Barnes & Noble
The Barnes & Noble Review
The Web may never be fast enough, but a whole lot's been learned in the past few years about building faster web sites. This book brings it all together, from optimizing content to tuning servers, scaling network infrastructure to building faster JavaServer Pages. This is in-depth stuff: detailed examples, measurement techniques, performance graphs, and dozens of solutions -- both "blunt instruments" and "scalpels."

Patrick Killelea begins with quick, preliminary recommendations for both the server and browser side: techniques that will make a significant difference in many, if not most, environments. Next, he reviews the planning and analysis techniques for identifying problems and acting proactively. You'll learn how to plan bandwidth, server, and memory capacity; automatically monitor each key performance parameter; test loads; and account for both reliability and security. Detailed case studies address several of the most widespread problems, including uncontrolled growth in database tables; logging delays caused by reverse DNS lookups; and database connection pool limitations.

Killelea then systematically reviews every link in the chain of Web performance: architecture, browsers, client and server operating systems and hardware; network connections; TCP/IP configuration; server applications; CGI; content; and much more. Killelea doesn't mince words: Java, he says, will never be adequate on the client side, but there are a raft of techniques for improving its performance on the server side (profiling, JITs, static compilation; adjusting runtime options). Whatever your role in maximizing web performance, whatever your application, you'll find this book indispensable. (Bill Camarda)

Bill Camarda is a consultant, writer, and web/multimedia content developer with nearly 20 years' experience in helping technology companies deploy and market advanced software, computing, and networking products and services. He served for nearly ten years as vice president of a New Jersey–based marketing company, where he supervised a wide range of graphics and web design projects. His 15 books include Special Edition Using Word 2000 and Upgrading & Fixing Networks For Dummies®, Second Edition.

Read More Show Less

Product Details

  • ISBN-13: 9780596001728
  • Publisher: O'Reilly Media, Incorporated
  • Publication date: 3/28/2002
  • Edition description: Second Edition
  • Edition number: 2
  • Pages: 480
  • Product dimensions: 6.80 (w) x 9.50 (h) x 1.14 (d)

Meet the Author

Patrick Killelea currently works for a major on-line brokerage, but he won't say which one. He spends his days writing monitoring and load testing tools, and proclaiming the web to the be the one true front end because of its simplicity, portability, and performance. He thinks Microsoft is not to be trusted with your back end. Patrick knows there are huge web performance improvements yet to be realized using the details of existing open protocols. He is a fan of T/TCP and hopes one day to set up a connection and deliver an entire web page all in a single packet. Patrick spends his evenings playing with his wife and kids, and is interested in etymologies, obscure religions, and pan-seared salmon with mixed greens and a nice merlot. He likes to get e-mail about web and Java performance issues. Please visit his web site at patrick.net.

Read More Show Less

Read an Excerpt


Chapter 11: Server Hardware

Here we revisit computer hardware from the server perspective. Even though each client receives exactly as many bytes as the server sends, the server hardware needs to be more powerful than client hardware because the servers must be capable of handling many clients simultaneously. On the other hand, it is common for small web sites to overestimate just how much server power they really need. if your server is handling only one client every several seconds, then you can probably make do with the same hardware that would make a good web client. For the majority of sites, the network connection is more likely than server hardware to be the limiting factor.

Server tuning is the subject of many entire books, and the subject is much larger than I can present in a single chapter. For in-depth detail, some good books on the subject are: System Performance Tuning, by Mike Loukides (O'Reilly & Associates); Sun Performance and Tuning, 2nd Edition, by Adrian Cockcroft (Prentice Hall); Configuration and Capacity Planning for Solaris Servers, by Brian Wong (Prentice Hall); and Optimizing Windows NT, by Russ Blake (Microsoft Press).

How Server Hardware Is Different

Box on a Wire

A web server is essentially remote storage that copies data from its RAM or disk to the network connection upon request. It may not be a simple copy, since dynamic content or database access may be involved, but from the user's point of view, your web server is just one more mass storage device. Now, does a disk drive have a windowing system? No. Similarly, your web server does not need a windowing system, a video card, a monitor, or even a keyboard! in fact, a windowing system occupies a great deal of RAM and CPU time, so it is a drain on server performance. You don't have any choice if you're using a Windows or Mac web server, but on Unix systems you can simply turn off X Windows. NT and Unix have an additional reason not to use a windowing system: the currently active window has a higher execution priority than other processes. On Solaris for example, processes belonging to the currently selected window are bumped up in priority by 10 points (out of 100 or so). If you're not very careful with the windowing system, you can hurt web server performance simply by moving the mouse. it is better to do web server administration remotely over one or more telnet sessions from a different computer.

Web servers without monitors are known as headless servers.

Good I/O

The fundamental distinguishing feature of server hardware is high-performance 1/0. Commodity PC hardware is limited by its legacy I/O subsystem, while server hardware is designed around 1/0 and can easily have ten times the I/O performance of the best PCs.

Multiple Busses

Servers usually have separate busses for L2 cache, 1/0, RAM, and peripherals. This reduces contention and allows the use of appropriate hardware for each bus, Server busses may be packet switched, in the sense that a request is made over the bus and the bus is released until the response is ready, allowing requests to be interleaved with responses and improving throughput. Bus throughput is critical for servers, because a great deal of what a server does is simply copy data between network devices and storage devices.

Fast Disks

Servers should have separate high-speed SCSI disks for content and logging. IDE disks are not acceptable. Striping data over disk arrays is highly recommended to allow seeks to proceed in parallel.

Lots of Memory

Servers should have large amounts of RAM to reduce disk accesses. A good rule is to allow enough RAM to hold the complete OS and the most frequently accessed parts of your data set. Servers also tend to have large L1 and L2 caches, and may have the cache split between data and instruction caches, because data and instructions have different access patterns. The only memory faster than L1 cache is the set of registers on the CPU. Many megabytes of L2 cache is becoming common.

Unfortunately, the effectiveness of caching for server CPUs is reduced by the context switching that happens with every network interrupt. httpd code and network handling code displace each other from the caches.

Scalability

A server should be scalable to smoothly handle an increasing workload. Unix workstations have far more capacity for scaling by adding CPUs and RAM than PCs. Unix workstations scale up to 64 or 128 CPUs, depending on whom you ask, while PC hardware cannot generally handle the contention between more than 4 CPUs, as of this writing. Workstations also have better I/O bandwidth and more RAM expandability.

Network Interface Card

The Network Interface Card (NIC) provides the connection between the network cable and the server's bus. NICs fill a conceptually simple niche, but their variety reflects the many permutations possible between network cable, cable signalling protocol, and host computer bus. NICs take an incoming serial stream of bits and output a parallel stream onto the bus, and vice versa. Until recently, it could be assumed that the network connection would be far slower than the CPU and bus, but LAN network speeds have been increasing faster than CPU and bus speeds, so it is no longer a safe bet that your network card can be handled by your machine. Still, at the interface to the Internet, you can be fairly sure that your server will be more constrained by Internet access than by any other component, save perhaps disk.

NICs have on-board buffers, and a bigger buffer always gives you more flexibility. The buffer has historically been important for holding outgoing data until the network can deal with it all, but as mentioned, that situation is reversing, so the buffers will in the future tend to hold incoming data, waiting for the computer. In either case, a larger buffer makes a buffer overflow and consequent data loss less likely. Lost TCP/IP data is simply retransmitted, adding to overhead. Typically, 8bit Ethernet cards have 8K buffers, while 16-bit cards have 16K buffers.

When a NIC has a complete unit of data from the network and is ready to forward it on to the computer's bus, it generates a hardware interrupt, which forces the CPU to save its current state and run the network card interrupt handler, which retrieves the data from the NIC's buffer and fills a data structure in memory. Therefore, a critical performance factor is how many interrupts per second the CPU, memory, and bus can handle from the NIC.

Another important measure of a server is how quickly it can get data from RAM or disk out to the network interface. This involves copying data from one place in memory to another, which is typical of server activity. Data is copied from the server's memory to the network interface card memory. Given a 1500-byte outgoing Ethernet packet, the OS must copy it-probably 4 bytes at a time-from RAM or cache out to the NIC buffer, so this copy would require 375 bus cycles to complete. The bcopy or memcpy library calls are often used here, so the efficiency of your server's implementation of these library calls is significant. This is also where the implementation of TCP/IP in your kernel becomes significant. If you have a poor implementation, it probably means the wait between the NIC's interrupt and the retrieval of a packet from the NIC's buffer is large, so additional packets arriving on the NIC may not find sufficient buffer space and may be dropped or overrun data in the buffer. This results in a costly retransmission of the lost packet.

You will get the best performance from the most recent network cards. Many network cards can now be upgraded by loading new code into their flash memory. The latest non-beta release of this code should give you the best performance.

It is possible to sidestep the use of the CPU for retrieving NIC buffer data by using a "busmastering" NIC, which is capable of moving data directly between the NIC buffer and the machine's memory without interrupting the processor. Busmastering cards have a performance advantage over non-busmastering cards, but are more expensive, because they need more on-card intelligence. Intel has specified a method for interfacing NICs directly to PC hard disk, called the 120 specification, which will need operating system support. 120 should be available by the time you read this.

Bus

A bus is a set of parallel wires (usually 32, 64, 128, or 256 wires, plus error and protocol handling wires) embedded in a board forming the backbone of the computer. Other components, including CPU, disk, memory, and network cards, are connected to each other by their shared bus.

There may be more than one bus in a computer. PCs may have only one bus connecting everything. Server hardware, however, typically has at least two separate busses: a high-speed bus for connecting memory to the CPU, and a slower bus for connecting 1/0 to the CPU. System busses lag CPU speed by a large margin, meaning that CPUs spend a great many cycles simply sitting and waiting for the bus to catch up. On the other hand, busses are usually faster than network connections. As already mentioned, this has been changing recently. Fast Ethernet, for example, runs at 100Mbps, which is more than ISA or EISA busses can handle. Gigabit Ethernet runs at 1000Mbps, which is even more of a challenge. At gigabit rates, the server bus and CPU generally become the bottleneck, especially if the CPU is trying to do database access or run CGI applications at the same time.

While a throughput of 1056Mbps from a 32-bit 33MHz PCI bus is technically possible, your true throughput will be far lower because of contention, network packet overhead, OS implementation, and many other issues. 10Mbps is good TCP/IP throughput for a PC. A Sun Ultra 1 should get much better than 40Mbps of TCP/IP throughput. (The advertised rates you see will be the far higher theoretical rates.) The 66MHz PCI bus exceeds memory access speeds, moving the bottleneck to RAM.

Multiple PCI busses, provided on some Compaq PCs, may give you parallel access to peripheral devices. Sun uses the IEEE 1496 standard for its peripheral SBus, but recently started building machines with PCI peripheral busses, so you can use offthe-shelf PCI cards if you install Sun-specific device drivers. Sun implements 64-bit PCI at 66MHz for the throughput needed for 622Mbps ATM, gigabit Ethernet, and Fibrechannel....

Read More Show Less

Table of Contents

Preface;
What Is This Book Good For?;
Audience for This Book;
Assumptions of This Book;
How This Book Is Organized;
Font Conventions;
How to Contact Us;
Web Site Updates and Code Examples;
Other Books and Resources;
Disclaimer;
Acknowledgments for the Second Edition;
Preliminary Considerations;
Chapter 1: The Quick and the Dead;
1.1 Questions for the Browser Side;
1.2 Questions for the Server Side;
1.3 Key Recommendations;
Chapter 2: Web Site Architecture;
2.1 Trade-offs;
2.2 Elements;
2.3 Example Web Site Architectures;
2.4 Trends;
2.5 Sample Configurations;
2.6 Key Recommendations;
Chapter 3: Capacity Planning;
3.1 Do the Math . . .;
3.2 . . . But Trust Your Eyes More than the Math;
3.3 Questions to Ask;
3.4 How Much Bandwidth Do You Need?;
3.5 How Fast a Server Do You Need?;
3.6 How Much Memory Do You Need?;
3.7 Key Recommendations;
Chapter 4: Performance Monitoring;
4.1 Parameters of Performance;
4.2 Latency and Throughput;
4.3 Utilization;
4.4 Efficiency;
4.5 Monitoring Web Performance Using Perl;
4.6 Automatically Generating Monitoring Scripts Using Sprocket;
4.7 Using a Relational Database to Store and Retrieve Your Monitoring Data;
4.8 Monitoring Machine Utilization with rstat;
4.9 Monitoring Per-Process Statistics;
4.10 Generating Graphs from ps Data;
4.11 Monitoring Other Things;
4.12 Making a System Dashboard Web Page;
4.13 Key Recommendations;
Chapter 5: Load Testing;
5.1 Load Test Preparation;
5.2 Trade-offs with Load Testing Tools;
5.3 Writing Your Own Load Testing Tools;
5.4 Benchmark Specifications and Benchmark Tests;
5.5 Other Resources;
5.6 Key Recommendations;
Chapter 6: Performance Analysis;
6.1 Using analysis.cgi to Find a Bottleneck;
6.2 Snooping HTTP with Sprocket;
6.3 Look at Connections;
6.4 Log File Analysis;
6.5 Hits per Second;
6.6 A Few More Tips;
6.7 Key Recommendations;
Chapter 7: Reliability;
7.1 Typical Failures;
7.2 Dependencies;
7.3 Smoothing Outages;
7.4 Key Recommendations;
Chapter 8: Security;
8.1 HTTPS and SSL;
8.2 Firewalls;
8.3 Bastion Hosts;
8.4 chroot;
8.5 Key Recomendation;
Chapter 9: Case Studies;
9.1 Database Table Growing Without Limit;
9.2 Reverse DNS Lookups Slows Logging;
9.3 Kinked Cable;
9.4 Database Connection Pool Growth Limits Performance;
9.5 Key Recommendation;
Chapter 10: Principles and Patterns;
10.1 Principles of Performance Tuning;
10.2 Patterns of Performance Improvement;
10.3 Key Recommendations;
Tuning in Depth;
Chapter 11: Browsers;
11.1 How Browsers Work;
11.2 Types of Browsers;
11.3 The Perfect Browser;
11.4 Browser Speed;
11.5 Browser Tuning Tips;
11.6 Non-Browser Web Clients;
11.7 Key Recommendations;
Chapter 12: Client Operating System;
12.1 Microsoft Windows;
12.2 Macintosh;
12.3 Unix;
12.4 Key Recommendations;
Chapter 13: Client Hardware;
13.1 CPU;
13.2 RAM;
13.3 Cache;
13.4 Bus;
13.5 Disk;
13.6 Video;
13.7 BIOS;
13.8 Key Recommendations;
Chapter 14: Lines and Terminators;
14.1 Forwarding and Latency;
14.2 Your Modem, the Information Driveway;
14.3 ISDN;
14.4 Cable Modems;
14.5 xDSL;
14.6 Higher Capacity Lines;
14.7 Intranets;
14.8 Network Modeling Tools;
14.9 The Internet;
14.10 PTTs;
14.11 Key Recommendations;
Chapter 15: Network Protocols;
15.1 Power and Protocols;
15.2 Factors Affecting Network Protocol Performance;
15.3 The Protocols of the Web;
15.4 Key Recommendations;
Chapter 16: Server Hardware;
16.1 Box on a Wire;
16.2 Good I/O;
16.3 Multiple Busses;
16.4 Fast Disks;
16.5 Lots of Memory;
16.6 Scalability;
16.7 Network Interface Card;
16.8 Bus;
16.9 Memory;
16.10 RAM Characteristics;
16.11 CPU;
16.12 Symmetric Multiprocessing (SMP);
16.13 Disk Activity and PID;
16.14 Key Recommendations;
Chapter 17: Server Operating System;
17.1 Unix and the Origin of the Web;
17.2 Unix Flavors;
17.3 System Calls Versus Library Calls;
17.4 Processes and the Kernel;
17.5 The Filesystem;
17.6 The Windowing System;
17.7 Versions and Patches;
17.8 Configurable OS Parameters;
17.9 Unix OS Monitoring Tools;
17.10 System Call Tracers;
17.11 Network Snooping Tools;
17.12 How Many Connections Can My Server Handle?;
17.13 How Many Processes Can My Server Handle?;
17.14 How Quickly Can My Server Fork New Processes?;
17.15 Unix Versus NT as the Web Server OS;
17.16 The Exokernel;
17.17 Key Recommendations;
Chapter 18: Server Software;
18.1 The Evolution of Web Servers;
18.2 System Calls Made by a Web Server;
18.3 How Servers Fail;
18.4 Configuring Apache and Netscape Web Servers;
18.5 Other Servers;
18.6 Missing Features;
18.7 Proxy Servers;
18.8 Hierarchical Caches;
18.9 Key Recommendations;
Chapter 19: Content;
19.1 Size Matters;
19.2 As Good As It Gets;
19.3 Caching and Differences;
19.4 HTML and Compression;
19.5 Performance Tips for HTML Authors;
19.6 The Document Object Model;
19.7 Graphics;
19.8 Audio;
19.9 Video;
19.10 Key Recommendations;
Chapter 20: Custom Applications;
20.1 Programmers;
20.2 CGI Programs;
20.3 CGI Internals and Performance Problems;
20.4 General CGI Tips;
20.5 CGI Language-Specific Optimization Tips;
20.6 Daemonize It;
20.7 CGI Database Access Performance;
20.8 Logging;
20.9 NSAPI and ISAPI;
20.10 DOM;
20.11 JSP, ASP, PHP;
20.12 Key Recommendations;
Chapter 21: Java;
21.1 Java Will Never Be Good Enough for GUI Applications;
21.2 Java Is Good Enough for the Server Side;
21.3 Performance Problems Intrinsic to Java;
21.4 Coding Tips;
21.5 Compilers;
21.6 Profile Your Code;
21.7 Decompilers;
21.8 OS-Level Profiling Tools;
21.9 JITs;
21.10 Static Compilers;
21.11 Virtual Machines;
21.12 Runtime Options;
21.13 Java Chips;
21.14 Java Benchmarks;
21.15 Web Sites with Java Performance Info;
21.16 Key Recommendations;
Chapter 22: Databases;
22.1 Do You Really Need a Relational Database?;
22.2 Performance Tips;
22.3 How Many Connections Can Your Database Handle?;
22.4 When the Database Is Overloaded;
22.5 Analysis;
22.6 Key Recommendations;
Web Performance Product Lists and Reviews;
Problems with Commercial Tools;
Monitoring Tools;
Load Generation Tools;
Preloaders;
Network Optimizers;
IP Traffic Management Products;
Content Compressors;
Hybrid Development Tools/Databases;
Java Profilers and Optimizers;
Caching Services;
Professional Services;
Load Balancers;
Modeling Tools;
Colophon;

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)