This is the second of a two-part newsletter on “going big”. By “going big” I mean how one transitions from a Web site with little to moderate traffic, to one that can handle tons of traffic. The previous newsletter looked at going big from the macro perspective: theory, implementation, hardware, and networking. In this newsletter, I’ll look at the micro perspective: how to write code that scales well. And, as it turns out, this newsletter again got to be too big, so this is part one of two parts that makes up part two of the two-part series. (Huh?) In this newsletter, I’ll mostly focus on code. The next will mostly focus on the database.
Before going into details, I’m going to define what it means to be a “big” site. As I said in the previous newsletter, it actually depends upon the kind of content and activity the site has: X number of video requests is far more demanding than the same X number of mostly text pages. Likewise, X number of WordPress page requests is far more demanding than the same X number of static HTML page requests. For the purposes of this discussion, let’s say that “big” is a site that gets in the broad neighborhood of 100,000 to 500,000 pageviews per day. At that point (if not before), you’ll need more than one server to handle the load. (As a counterpoint, on the highest end, Netflix sometimes requires up to 20,000 servers at a single time.)
As always, questions, comments, and all feedback are much appreciated. And thanks for your interest in what I have to say and do!
Continue Reading...
