Editor's note -- In the world of Web publishing, lots of effort goes into building functionality, and to some degree into designing user interface, but performance tuning is often overlooked in the mad rush to get to the next project.
Patrick Killelea believes that performance tuning deserves equal attention alongside other Web publishing tasks, and he's mapped out an excellent approach in his latest O'Reilly book, Web Performance Tuning, 2nd Edition. You can take a look at a sample chapter online that covers Performance Monitoring to get a feel for his approach.
But if you want to get right to the important stuff, take a look at Patrick's top ten performance tips below. These are definitely worth bookmarking.
Check for standards compliance by using Weblint or other HTML checking tools.
Content that conforms to the HTML 4.0 standard will load faster and work in every browser because the browser then knows what to expect. Note that Microsoft-based tools create content that does not even use the standard ASCII character set, but instead uses many proprietary Microsoft characters that will display in Netscape as question marks and can slow down rendering.
Fast by DefaultVelocity Online Conference
Dec 8, 2009
Sharpen your Web Performance and Ops skills right now! Use discount code "velfall09d25." Register Now & Save 25%
Turn off reverse DNS lookups in the Web server.
If left on, reverse DNS will log a client's machine name rather than IP address, but at a large performance cost. It is better left off. You can always run log analysis tools which look up the names later.
Try out a free analysis tool.
I've provided a free analysis tool at my Web site that can tell you whether or not your bottleneck is in DNS, or because of connection time or content size, or is on the server side. Work on improving the slowest part first.
Use simple servlets or CGI.
Use simple servlets, CGI, or your Web server's API rather than any distributed object schemes like CORBA or EJB. Distributed object schemes are intended to improve a programmer's code-writing productivity, but they do so at an unacceptable cost in performance for end-users.
Get more memory.
Your Web server, middleware, and database all will probably do better with more memory, if they still use their hard disks frequently. Hard disks are literally about a million times slower than memory, so you should buy more memory until the disks are phased out.
Index your database tables well.
Spectacular improvements are possible if you are inadvertently doing full-table scans on every hit of a particular URL. Indexes allow you to go directly to the data you need.
Make fewer database queries.
If you can cache content in your middleware or servlets, do it. Making connections to a database and using those database connections is typically a bottleneck for performance.
Look for packet loss and retransmission.
There are many network snooping and monitoring tools to help you do this. Intermittent slowness is often due to packets being lost or corrupted. This is because a time-out period needs to pass before the packet is retransmitted.
Set up monitoring and automated graphing of your Web site's performance.
This information is free online in Chapter 4 of the second edition of Web Performance Tuning.
O'Reilly & Associates recently released (March 2002) Web Performance Tuning, 2nd Edition.
Sample Chapter 4, Performance Monitoring, is available free online.
For more information, or to order the book, click here.
Patrick Killelea currently works for Sun Microsystems Professional Services.
Return to the Web Development DevCenter.
Copyright © 2009 O'Reilly Media, Inc.