November 4, 1996
How We Made Our Site Faster
By Bob O'Donnell
The Internet was originally designed for collaboration and learning among universities,
and one of the great things about the Web's success is that this environment has extended
into the business world. Most members of this all-encompassing, virtual community are
eager to share their particular knowledge and experiences with each other for no other
reason than the desire to teach; a rather noble goal in my book.
Similarly, or perhaps as a result, there's also a great deal of interest in learning.
Confronted with the vast amount of information now available, most individuals on the Web
can't help but be more inquisitive about a wide range of subjects. There's particularly
strong interest in learning more about real-world experiences with the Web itself.
So, it wasn't entirely surprising that I received a flood of e-mail after my recent
column on the performance problems we were having with our site. [See Plugged In,
Sept. 30.] Many appreciated an acknowledgment of the problem and a large percentage
asked me to share our solutions with them in the hope of learning things that they could
apply to their own situations.
I'm happy to be able to discuss these issues this week because, in case you hadn't
noticed yet, InfoWorld Electric is much faster now. It's now near perfect -- dial-up
connections, in particular, are still somewhat painful -- and we aren't finished with our
work, but I hope you'll agree that the site is now much more usable. In the collegial
spirit of the Web, I want to share with you what we did to make it so.
A bit of background first. Like many organizations, we recently moved the technical
management and upkeep of our site to our IS department. It previously rested with the
content creators, us folks in editorial. The move wasn't entirely without controversy and
we're still working out some of the kinks. The problem is, we editorial types had gotten
used to being able to request things of our technical staff and have them happen, or at
least get started, right away. As the site grew more complex and the number of technical
issues exploded, however, we ultimately decided it was better to have the slow, methodical
IS approach to site fixes and developments rather than the freewheeling, but somewhat
haphazard, approach taken by editorial people unaccustomed to dealing with technical
development projects.
So, once the IS staff stabilized our environment for a few weeks and analyzed the
situation, they began their work. The first step involved finding a series of real-world
benchmarks they could use to accurately monitor any performance improvements. They created
six simple utilities that measure the server's average response time, total response time
(for a script with 58 requests), average client throughput, active HTTP connections,
average connect time, and number of errors. They also created an overall speed index by
multiplying the average client throughput by the number of active HTTP connections. The
tests were (and continue to be) run automatically every hour, via a T1 connection two hops
from our site, and the results tallied.
Once the initial week of performance numbers were stored, the fun stuff started. They
began by applying patches to the operating system. We were running Irix 5.3 on a SGI
Challenge S server with 96MB of RAM along with Netscape's Commerce Server 1.0, both of
which were several versions out of date. They applied 16 different IRIX patches and added
another 32MB of RAM, bringing the total to 128MB.
The next step involved OS tuning. The IS group reconfigured the kernel by changing a
number of TCP/IP networking settings, including increasing the number of pending socket
connections from five to 255 and decreasing the amount of time the server waited for
dropped connections. These changes amounted to the silver bullet we had been hoping for.
Our benchmarks showed a 10-fold improvement in the total response time, a 7-fold
improvement in average response time, and a 4-fold improvement in client throughput. Other
measurements were similarly improved.
But as I mentioned earlier, we're not done yet. We still need to install the latest
versions of Irix (6.2) and the Netscape server (Enterprise 2.0), which combined, I'm told,
will again double performance. To ease the transition and reduce potential problems with
our production server, we've purchased an additional SGI Challenge machine on which we
will make and test these and possibly other improvements. When we're confident the system
is working well, we'll cut over to the new machine, then install those changes and others
on our existing production server. We'll continue the leapfrog process as long as
necessary and then may dedicate two mirrored servers to our site (in addition to separate
staging and database servers), which should again give us a good performance boost --
though not necessarily doubled.
Ultimately, what this means is that the time you spend with us here on InfoWorld
Electric will be a lot more productive. With the current and forthcoming improvements, I
hope you'll take the time to explore more of the site, from our interactive forums, to our columnists, to
our week
in review. And as always, let us know what you think.
©
Copyright 1996, by InfoWorld Publishing Corp., a
subsidiary of IDG Communications, Inc. Reprinted from InfoWorld,
155 Bovet Road, San Mateo, CA 94402. Further reproduction is prohibited.
