In our last article on performance tuning, we examined how to squeeze the most performance out of an Apache server. In this installment, we’ll take a look at how to apply some of these same principles to Microsoft’s Internet Information Server (IIS), which ships as part of Windows Server.
While its percentage of the Web server market share has declined in recent years relative to Apache, IIS still remains the second most deployed Web server on the Internet. Its deep integration with Windows and host of management utilities make it a great choice for anyone hosting Web content and applications in a Windows environment. With a little performance tuning (aided, of course, by load testing), an IIS machine can perform just as well as an equivalent Apache configuration under high load.
The Usual Suspects: Compression and Connection Management
Many of the techniques a team might use to enhance IIS performance are similar to the techniques used on Apache, as they involve configuration of the HTTP protocol.
So far in our series of Web Performance articles, we’ve addressed the three majors types of caching that Web server application developers can employ: server file caching, application caching, and data caching. We’ve looked at additional performance enhancements that Web server administrators can can activate, such as HTTP compression, file consolidation, and connection pipelining.
In this latest installment of our series, we’re going a little deeper and focusing on Apache. The world’s most popular Web server, Apache currently powers over 63% of sites on the World Wide Web. While Apache runs decently out of the box, development teams and system administrators should combine frequent load testing with the following tuning recommendations to ensure their applications perform well under heavy traffic.
Memory Models: Prefork vs. Worker
A Web server must be able to respond to anywhere from dozens to thousands of concurrent user requests. Each request, obviously, must be fulfilled by either a separate application process, or a separate thread running within a single process.
Apache can handle concurrent requests in two different ways, depending on which Multi-Processing Module (MPM) was selected at compile time. The default MPM on Unix is prefork, which handles each separate user request in a separate instance of Apache. The other MPM module available for Unix systems is worker, which launches fewer instances of Apache, and handles multiple requests in separate threads within each process.
Worker is the preferred MPM module for Apache under Unix, as it is faster and uses less memory. So why is prefork the default? Because any team that deploys worker must ensure that any modules that run under Apache are thread-safe. The thread-safe requirement extends to any libraries used by these modules, which makes running a programming environment such as PHP under worker tricky: while PHP is itself thread-safe, there is no guarantee that its various extensions are. Some developers, such as Brian Moon, have reported success in running PHP under worker using a minimal set of extension libraries. Your mileage, however, may vary.
As we’ve discussed previously, Web site optimization directly affects a company’s bottom line. A sudden traffic spike that swamps a website’s capacity can cost a company thousands or even tens of thousands of dollars per hour. Web servers and Web applications should be built and deployed from day one with performance at the forefront of everyone’s mind.
Web site administrators and web application developers have a host of tricks and techniques they can employ to deliver Web pages more quickly. From my experience, I’ve seen 1,000% performance improvement from simple web application optimization techniques. Caching is the #1 tuning trick in the web developers kit. Customers ask me weekly what I recommend for speeding up their app. I always start with “caching, caching, and more caching”. It’s like magic for a site.
A ViSolve white paper shows a return on investment of $61,000 for a $20,000 total cost of ownership of only two caching servers!
In this article we’ll look at how two different but related forms of caching are used to conserve server resources and reduce network latency; thus, greatly improving your customers’ experience with your site.
What is Caching?
Caching refers to any mechanism that stores previously retrieved content for future use. As I learned it in college back in the VAX/VMS operating systems class, it is temporarily putting something into memory that you will use again in order to avoid hitting the hard drive. Computer scientists today are less concerned about saving every byte like we were back then. Still, web applications are constantly re-using data and files; so why in the world would we want to make an expensive hit to the database? Hard drives can be 10,000 times slower than memory because they are mechanical and must move to the correct position and spin to the exact spot where data exists. Memory moves at the speed of electricity.
The goal of caching is to increase the speed of content delivery by reducing the amount of redundant work a server needs to perform. Putting a file in memory to re-use it can save millions of drive accesses; thus, the speed of getting the browser what the user needs is increased by magnitudes. Caching and performance go hand-in-hand. It’s a no-brainer.
On February 4, 2004, an enviable fellow geek shared a strange new website with the rest of the world that would literally impact everyone’s class reunions forever. Today is the 7th birthday of Facebook.
Sites Can Grow Exponentially
The four founders were Harvard students and started the site from their dorm room. The idea was only for college students. It’s immediate popularity drove them to expand to Columbia, Yale, and Stanford – within 1 month!
It only took Facebook 10 months to reach 1 million active users!!
It is not hyperbole to say that this single web application not only change the life of college students, but eventually the world as a whole. Initially it was a way for young men to creep on hot girls and find other students for sharing class notes or previous tests has now evolved into a way for young men to creep on hot girls and pretend they didn’t see their grandmother’s posting of their baby pictures.
This little college website now is a huge marketing phenomenon with about one-half a BILLION people signed up and 50% of those are on the site daily. It has guaranteed that anyone who was living the single college carefree lifestyle in the past 5 years will always have a haunting fear that an incriminating picture will expose their sins later in life. I guess the future Bill Clintons won’t be running for president after all. Facebook has changed our lives in ways we can’t imagine. I wonder how many marriages will end from the distrust created by the stomach-turning photo of a spouse (from earlier days) found through a tag notice.
I bring you a blog post I found today about performance testing and improvement, but first….
On this day in 1895, physicist Wilhelm Conrad Rontgen (1845-1923) becomes the first person to observe X-rays. Like most other tremendous breakthroughs, Rontgen’s discovery occurred accidentally in his Wurzburg, Germany, lab, where he was testing whether cathode rays could pass through glass when he noticed a glow coming from a nearby chemically coated screen. He dubbed the rays that caused this glow X-rays because of their unknown nature.
X-rays are not useful to increase the performance of your web sites, but it sure would be helpful if we had a way to easily see inside our web system architecture to spot the bottlenecks and inefficiencies. Wouldn’t it be cool to run a scan on a site and be able to quickly see a performance problem like the big bump on this guy’s hand? Maybe that was Wilhelm’s wedding ring. Or maybe he should have stopped cracking his knuckles when his mom told him to “quick that nasty habit!”
This blog was posted today and provides some quick suggestions for improving web site performance. How To Enhance The Online Performance Of Your Website by Kabir Bedi presents some basic tips that are useful.
Here are a few good insights about software performance from Robert Read in his eBook entitled, How to be a Programmer: A Short, Comprehensive, and Personal Summary. Robert dedicated the book to his colleagues at Hire.com.
My favorite parts are listed here as excerpts and included below in the original context:
- Bottlenecks in performance canl be an example of counting cows by counting legs and dividing by four instead of counting heads.
- The purpose of stress testing is to figure out where the wall is, and then figure out how to move the wall further out.
- If the wall is too close to satisfy your needs, figure out which resource is the bottleneck (there is usually a dominant one.) Is it memory, processor, I/O, network bandwidth, or data contention?
- Performance is a part of usability.
- Most software can be made (with relatively little effort) 10 to 100 times faster than they are at the time they are first released.
- If a well-isolated algorithm that uses a slightly fancy algorithm can decrease hardware cost or increase performance by a factor of two across an entire system, then it would be criminal not to consider it.
- A plan for stress testing should be developed early in the project, because it often helps to clarify exactly what is expected. Is two seconds for a web page request a miserable failure or a smashing success? Is 500 concurrent users enough?
- I’ve made errors such as failing to provide a relational database system with a proper index on a column I look up a lot, which probably made it at least 20 times slower.
- Other examples include doing unnecessary I/O in inner loops, leaving in debugging statements that are no longer needed, and unnecessary memory allocation.
- Stress testing is fun.
- Who has particular knowledge about a component also constantly changes and can have an order of magnitude effect on performance.
- Finding the expensive I/O and the expensive 10% of the code is a good first step
- There is not much sense in optimizing a function that accounts for only 1% of the computation time.
- Each change brings a test burden with it, so it is much better to have a few big changes.
CTOs Don’t Get It
One of the most disruptive events at organizations is the disconnect between decisions made by managers and the views of those decisions by employees. Does this situation sound familiar?
In the spirit of New Year’s resolutions, I’m going to try to provide as many tips of the week as I can. There are weeks when I might get too busy, but I’ll sincerely try to post a small hint or trick that will be helpful to web developers. Tips may be about load testing, performance testing, performance tuning, stress testing, or anything related to web application development.
Performance Reference Point
I saw a tweet today that referenced web performance improvement, and that linked me to an interesting post on Developer.com.
I was in a meeting this morning with our development team, and we have a desire to run some load tests against Drupal. We want to find out how Drupal performs on a standard Amazon EC2 small instance. We believe LoadStorm can do a good job of stressing an out-of-the-box Drupal application implementation. Not sure if we want to use a LAMP or MS stack yet, and we are open for suggestions.
Anybody interested in this type of tech study?
It depends. Stress testing tools can be invaluable for finding the breaking point for a web application. But even the best tool and test plan won’t fix the problem.
The purpose of stress and load testing is to discover. Measuring response time and errors relative to user volume can point to solutions; however, the developer(s) must engage in performance tuning to eliminate bottlenecks or otherwise improve throughput.