Blake Schwendiman's Blog and Blook

Last week I wrote about the good and bad of technology. What I should have been writing about is the complexities of getting the things that should just work to actually just work.

I think I figured out what was wrong with my web server. I'm going to geek out for a minute, but then I'm going to relate it to the real world. What happened with my server is that because I get so much traffic from my Google modules, I had tried to increase overall server performance by allowing more copies of the web server software to run. This is something you can do. I had set the max number of servers to 250 which theoretically means that 250 concurrent instances of my web server software were allowed to run at a time. I thought this would be better than only allowing 100 to run since there are so many requests all the time all day long.

What I learned, though, was that allowing that many copies to run actually bogged down my server to the point that each new request made the machine run exponentially slower. So during periods of peak demand (morning, lunch time and end of the day), my server would become unresponsive as 250 instances of Apache tried to concurrently access disk, database and memory resources. Yesterday I reduced the number of concurrent instances to 128. Things have been much better since then. I'm not sure if there's a formula for figuring this thing out in advance, but it would be nice to know.

The real world lesson should be obvious. Sometimes in life we attempt to do too many things concurrently. When that happens, everything suffers and the quality of our results on each individual task is likely to decrease. However, if we can learn to queue up tasks -- that means that we acknowledge them, but schedule them for later -- we can focus on our optimal number of concurrent tasks, finish them quickly and effectively, then move on to the next things.