Archives For
newsletter

This is the third and final issue of my two-part newsletter on “going big”. (Yes, third in a two-part series.) 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 first newsletter looked at going big from the macro perspective: theory, implementation, hardware, and networking. The second newsletter was the first look at the micro perspective: how to write code that scales well. The emphasis there was on the code itself, along with the development process.

In this newsletter, I’ll provide a couple of resources for two other key components: the underlying database and the user’s browser. As always, questions, comments, and all feedback are much appreciated. And thanks for your interest in what I have to say and do!

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!

The subject of this newsletter is “going big”. By that I mean how to transition from a Web site with little to moderate traffic, to one that can handle tons of traffic. (How you get the traffic itself is an entirely different issue.)

To be entirely forthcoming, “going big” is not my forte, which is to say that I don’t have a ton of direct, personal experience in this area. Among the X dozens of Web sites I’ve worked on over the past 14 years, only a smattering have the demands of a “big” or “big-ish” site. Which makes sense, as statistically, not that many sites are “big”. In the grand scheme of things, the number of “big” sites is such a small percentage as to be almost negligible. This is fact I’ll speak more about at the beginning of this newsletter.

That being said, I do know a fair amount about the subject, and I know, and have spoken in detail with, people that are directly responsible for heavily trafficked sites. So, although I’m not an expert in “going big”, I’m not just guessing here, either.

As I was writing this newsletter, it also became “big” (as in wordy), so I’ve split it into two. This, the first, looks at going big from the macro perspective: theory, implementation, hardware, and networking. In the next newsletter, I’ll look at the micro perspective: how to write code that scales well.

As always, questions, comments, and all feedback are much appreciated. And thanks for your interest in what I have to say and do!

Last year was a fairly active one for me in terms of public speaking. I spoke at four events, each quite different than the next, and I really worked hard on becoming a better public speaker. (Those two activities–public speaking and working on becoming a better public speaker–don’t always go hand-in-hand, sadly.) Over the course of the year, I learned quite a bit, both about myself and about public speaking in general. In this newsletter, I thought I’d share some thoughts and resources along those lines.

As always, questions, comments, and all feedback are much appreciated. And thanks for your interest in what I have to say and do!

It’s the beginning of a new year, which makes it an apt time to talk about resolutions. But I’m not really a resolutions kind of person. Instead of resolutions, I prefer goals, specifically work goals. (And by “prefer”, I mean that it’s something I’ve finally started purposefully thinking about in the past couple of years.) I often get asked about what kinds of things developers should learn, so a good portion of this newsletter will be goals you could set towards that end. You’ll also find links to my 2013 goals, and a recap of how well my 2012 resolutions, er, goals, were met.

About Larry Ullman

Larry Ullman is a writer, developer, teacher, speaker, and consultant. He has written more than 20 books and numerous articles. His books have sold over 400,000 copies world wide in more than 20 languages. As his readers, students, and co-workers can attest, Larry’s strength is in Translating Geek into English: converting the technical and arcane into something comprehensible and useful.

After 14 years of working for himself, Larry joined Stripe in 2013. He is currently a Technical Writer there.