Blue Sky On Mars

I just added “and lived to tell the tale” to my posting. Yes, the site did just fine with the slashdotting.

Yeah, this is not much more than hot-air marketing…and does the pledge site actually do anything other than replicating functionality that basic HTML pages could do? Doesn’t appear to be anything dynamic about it, other than the very basic pledge-signing form.

I would HOPE a Slashdotting of those pages would have no effect!

Actually, there’s far to little consideration for load scenarios among python web programmers.

Hopefully you know beforhand a slashdotting that your site’ll hold up. The way to knowing that is to prepare for it.

Sure idle pride is all pretty narcism, but contribution to a body of knowledge is better.

Here’s how I make things scale.

* Caching Proxy
* Load balancer to a server farm
* one app process handles about 16 full dynamic requests per second
* per machine I can spawn about 3 such processes before performance degrades
* per database I can spawn about 5 such machines before the db slows down (oracle)

==> ~240 fully dynamic rendered requests per second. However the caching proxy handles thousands of requests per second and most don’t hit trough to the app at all.

Max response time per thread in this scenario is 6 seconds (response time drops dramatically per thread when the load is a little relieved.

So how about you? Did you just get lucky you survived slashdotting?

Florian, I disagree. The Django project talks a fair bit about coping with load.

Florian: Sorry for dismissing your original comment, which was something that I’m certain that some people would be curious about. I don’t think I would have had it not been for Joseph’s comment which was a bit more flippant.

While I do care about raw throughput to an extent (and there are a couple of efforts underway that will doubtless improve TurboGears’ raw throughput), if that was the primary concern I’d be coding in Java or C.

To me, a far more interesting than “how was it set up” would be “how did you predict how much traffic you’d get?”

Ability to scale has so much more to do with application design than raw throughput. If you manage to have a reasonable idea of what kind of traffic you’re going to get, you can choose an application design that makes sense. If you’re writing an app that runs on an intranet for 10 people, you can pretty much write the code however you want. If you’re going to be slashdotted in the first couple of days, you should design your data access, caching and user session handling intelligently. Partitioning of data, breaking pieces out into services and otherwise being able to shift load between boxes is the key.

DHH said it succinctly here: “It’s boring to scale with Ruby on Rails” (or TG or Django):
http://www.loudthinking.com/arc/000479.html

There’s even a book about scaling LAMP:
http://tinyurl.com/nj6r3

Since I wasn’t involved in the creation of this site, I can’t say what steps they took. As Joseph points out, there’s not a ton of dynamic stuff going on here, so making this site scale would not be very difficult.

Diggdot.us is more dynamic and does more work. I know that they’ve handled their traffic and spikes through caching and I believe they have a couple of boxes running.

Just coming in a bit late on this discussion… but just fyi here the main components of the design:

(and by the way, I’d agree with some of the previous commentary,
that there are loads of sites that involve much higher load than
this one, and are much more technically involved and brilliant…
we’re not trying to claim we invented the world. But having done
another site in Turbogears, we did manage to turn this site around
in a month from client briefing to launch, which we felt was good
(maybe only for us…, but hey, “personal bests” are the best
goals!)).

The designed project actually involves three separate site

1) the main irrepressible.info site, which allows people to sign
the pledge (supporting the amnesty campaign) and also take a
“fragment” banner on their own site or blog. (The fragment banner
effectively works very like a google adwords space)

2) an admin site where the client can add/edit the fragments of
“repressed” sites (the ones that “someone doesn’t want you to
read). We were interested in making this site a catalogue of
(politically) suppressed content, with an interface for people to
be able to submit new pieces of suppressed content, and thus
having this “admin” (or cms) partially open to the public.
Unfortunately, like so many real world projects turned around to
tight deadlines, clear client goals and slim budgets, many
non-core features had to be (initially) pared back…

3) a “fragments” site where the distributed “fragment banners”
would pull their content from.

The main concern for us in building the site, interestingly, was
not the slashdotting - because the main irrepressible.info,
as pointed out, isn’t very process intensive. Rather we were concerned about the
fragments site, because if the site was successful (that many
people with successful sites put the fragment-javascript on their
webpages) then there would be many many requests (intrinsically
uncached, in order that the fragments were always changing on the
client sites) on the fragments server - effectively a kind of DDOS
attack on ourselves! So we actually decided to make the
“publishing” of the fragments (a necessary step from the clients
brief in any case, as they wanted to sign off any fragments) an
(scripted) export of pages from a dynamic (the admin site) to a
largely static site (fragments). Keeping these two sites on
separate virtual hosts allowed us to use different technologies
(turbogears for the CMS and the main (dynamic) site and keeping largely
to pure-apache for the fragments site) as appropriate and also
enables us to move the fragments site onto a different process or
server if needed (given that we’re using largely vanilla apache
for this, it means that redeploying to a new server is largely a
matter of copying some files and repointing the DNS)

Ok - it’s fairly simple technological design underlying it (sorry, we never
claimed it was going to be clever…)… but maybe that’s a good
(or even clever) thing… And yes, we did some load-testing, and
no, sorry we’re not posting any graphs at present.