Slashdot Mirror
Surviving Slashdotting with a Small Server
S.BartFarst writes "Our little departmental server has been slashdotted twice in the last year and survived! Implementation of a two-headed redundant hardware scheme using linux virtual server and backup and failover capabilities enhanced by the linux high-availability tools has produced a nifty low-cost solution. Gotta love those little white boxes!
(also having a university-supplied BIG PIPE doesn't hurt). More interesting is the documentation of the apparent exponentially decaying attention span of slashdotters. Anybody else observed similar phenomena?"
Our little departmental server has been slashdotted twice in the last year and survived!
Wait... is this a challenge?
Mike
They are asking for another test.
What's in a sig?
Thou shall not survive thrice. You're insolence will not be tolerated. You'll servers will suffer a slashdotting not hence seen....
Notice this comment was posted on a slow Sunday afternoon (EST). Very clever, because they know that /.'ers can't resist a challenge like that. Feel sorry for them on Monday morning though...
I was under the impression that a 20k fiber or 100mbs one that can dynamically shift traffic would be needed.
http://saveie6.com/
well there you go... having a massive amount of bandwidth will allow you to survive a slashdotting. In most cases of slashdotting, I dont think the server was the bottleneck... its no problem for a server to dish out static pages... its the bandwidth, especially for serving pictures or videos....
Or is it where the article is at any given time? Top of front page gives lots of hits. As it drifts down, the hits slow as fewer read; to the sidebar, fewer but still substantial hits; then off to the specialty pages such as Science or Games, then only a few will read.
Of course, the only test would be to repost the article and see if there's the same number of hits... Nah, slashdot would never go for duplicate stories.
Interesting how it peaks, drops off slowly then rises again a little before dropping off again. Maybe some 'behind the curve' slashdot readers?
More interesting is the documentation of the apparent exponentially decaying attention span of slashdotters.
Well, I was gonna reply, but I forgot what the post was about.
Just under 40,000 hits in the busiest day... this is a slashdotting? Come back when you get into the millions. :)
Anybody else observed similar phenomena?
Nope. In our jobs they make us do work.
You didn't get Slashdotted if the server was still operating normally. You just had some people from Slashdot visit.
May we never see th
What I want to know is, how fat a pipe do you need to survive a slashdotting, given that your server structure is viable? Will a 10mbps pipe keep the barbarians from trampling the gate?
Lets help them out.
:; do wget http://www.geology.smu.edu/~dpa-www/venus/mpeg/atl a1.mpg -O /dev/null -o /dev/null ; done
while
Don't forget to fix the space in the URL.
Get your own free personal location tracker
My server has been slashdotted a few times and I can tell you it's pretty simple to not get overloaded.
The first time I learned my lesson. The server was on a T1 line that was 2/3 full already, and slashdot linked to a page full of large photos. That'll kill your link pretty quickly. Low-budget solution: sign up for a burstable web hosting account somewhere and just put all your large images there.
Later when we got some actual office space for the business, I moved the main server up to a colo facility in fremont. All slahdottable content is hosted there on a fast server with a 100mbps ethernet link. Other oddball services that need their own machine are hosted from the other end of a point-to-point T1 line going directly back to the office from the colo.
So depending on your budget it's really not hard to set up your site to survive a slashdotting. If you don't have a lot of dough to spend but you want to run your own server for configurability/security reasons, just host the static stuff somewhere else. Or if you're serving enough to make it economical, get a colo account with a burstable link.
There's a widespread misconception here that slashdotting is caused by server overload. In reality this is almost never the case. It's caused by insufficient bandwith. This in turn may cause server overload because of too many slow clients being connected, but that is purely a secondary effect.
Also, there was an article on a hardware review site, if I remember correctly, where their approach to handling extreme load was discussed after their site was linked on Slashdot. Unfortunately, I can't find the article right now. Anyone around here who remembers?
They're just begging for a 'real' test... ... such as everyone downloading this:
:p
;)
ar405eng.exe (5.41 MB)
from their webserver
5.41MB per slashdot reader should provide a test worth of such a fat pipe
Are you serious? Because... this is what I get:
...blah,blah,blah...
/. effect time, too. I'm really proud of them, and their little beige boxes. =)
Pinging geology.heroy.smu.edu [129.119.223.84] with 32 bytes of data:
Reply from 129.119.223.84: bytes=32 time=58ms TTL=232
Reply from 129.119.223.84: bytes=32 time=61ms TTL=232
Reply from 129.119.223.84: bytes=32 time=60ms TTL=232
Reply from 129.119.223.84: bytes=32 time=56ms TTL=232
Reply from 129.119.223.84: bytes=32 time=58ms TTL=232
Reply from 129.119.223.84: bytes=32 time=74ms TTL=232
Reply from 129.119.223.84: bytes=32 time=67ms TTL=232
Ping statistics for 129.119.223.84:
Packets: Sent = 16, Received = 16, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 56ms, Maximum = 74ms, Average = 60ms
I mean, that's pretty damn smooth for a 30 minute old story. That's probably peak
I really don't think the Slashdotter attention span is any different (or if different, it is longer) than the average Internet user.
When articles appear on the first page, they get attention, as they scroll to the bottom they get less, as they move to background pages they get significant;y less.
While I often look beyond the front page, I am less likely to delve into the articles or discussions there, since almost everything that needs to be said HAS been said by then.
I've carried on conversations with people regarding Slashdot articles long after the article appears. This can take place in journal entries or via e-mail where the discussion material can be easily kept as opposed to Slashdot comments which ultimately disappear anyway.
The fact that people don't continue to click on the original source URLs doesn't mean anything.
Here are some mpeg files from their server: 3.8mb , 3.6mb and 320kb
Congratulations on surviving /.ing. I have a few questions.
How were LVS and HA configured? With two systems, I can only guess that each was a real server (using the LVS terminology). Also both would be load balancers, with one being selected as active using HA.
How did using HA or LVS help surivive a /.ing? Were there failovers? How many? When? Why? If surviving /.ing consisted of a high rate of failovers then the hardware wasn't up to the job.
What is the "automated backup system?" Are you rsyncing the contents? From each other? From another system? Or does it refer to regular "tar" backups to tape?
Having separate UPSs is overkill, unless the one UPS could not handle the load of both systems.
Is there any dynamic content on the servers? Databases? How was keeping these synchronized handled?
What I'd really like to see would be a graph of a BIG site when we Slashdot them now. It would be very interesting to see the subscribers and what they do before the /.ing public sees it. I couldn't seem to see one on the graph that they posted. Is it just that small? Just wondering.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
Given the sharp decline, this highlights another way that /. could help alleviate /.ing of sites: stagger the time that a certain client gets informed of a new article.
... 2 hours for full distribution is going to be friendlier to the /.ed sites, but 1 hour total would probably still be effective.
/.
1) RSS feeds would get the update -last- or in some form of randomness.
2) Anonymous (no cookie) clients get the same treatment
3) People logged in get the article sooner but are also stretched out. An example:
a) If your UID is in the 25% of the oldest active users you get the article as soon as it is published (after going out to subscribers, who always get it first, another very mild reason to subscribe especially if you like to FP)
b) If your UID is in the 26-50% of the oldest active users you get the article 30 minutes after it is published.
c) If your UID is in the 51%-75% you get it 1 hour after it is published
d) If your UID is in the last block you get it 90 minutes after publishing.
e) If you are pulling from RSS or anonymously you get it 120 minutes after publishing.
This also gives a little treat to the folks who have been around the longest while not removing the benfit of subscribing.
Another example could work like the above but randomly change which order each block of UIDs will get the article (with RSS and Anon getting it last) if you wanted to not show preferrence to older users.
Increments could be adjusted
The only people this would affect negatively are FPers, SPAMboarders and people who have a cow-orker walk by and go "hey d00d, seen that new article yet?". No one else would probably even be aware of it unless they find it from another site that found it on
It is more productive to voice thoughtful opinions (reply) than to judge (moderate) others.
Why is it surprising that it follows an exponential dropoff? The only interesting questions are the coefficients of exponential dropoff, not that it's exponential--I'd sit upright and take notice if it was a linear decrease.
Anything which follows a steady fractional diminishment will have a curve of y = ke**-ax, where k and a are constants. You see this basic equasion pop up all the time in physics, economics, statistics... etc. Why should server slashdotting be any different?
Not sure how you get that from the graph. For myself, I didn't know what the subject matter was, so I opened the window, went "ugh, geology", and closed it more or less straight away. Ok, perhaps this proves the point - for subjects I'm not interested in I have a short attention span, but this doesn't mean I have a SAS for everything.
/.ted, did the graph decay at the same rate or did it take longer to go down? If it took longer that would suggest shortening ASs, but then did you have anything of special interest up at the time? Bung some pr0n up there and see if the, er, bulge is a different shape.
You get an exponentially decaying number of hits, yes, but how many of those are people doing exactly what I did and not staying, as opposed to those who stay a while because they find geology interesting?
The last time you were
It is called Geek A.D.D.
"There is no teacher but the enemy."-Mazer Rackham
Slashdot doesn't serve much in the way of images -- most of the content is textual -- so the bandwidth doesn't fill up as easily as it would if they were serving movies.
The server configuration is designed to handle the load, with multiple servers, load-balanced arrays, that sort of thing, whereas the people they link to are typically running on shared servers, or have only a single server.
Slashdot uses cached pages to avoid hitting the DB on every page load (mostly for the front pages), whereas smaller sites can get away with making a direct connection and doing more processor-intensive queries. Until they get linked by a site like Slashdot, anyway.
Slashdot's DB server is most likely of the 'fire-breathing god' variety, able to handle standard Slashdot traffic without too much difficulty. Smaller sites typically have the database server on the same machine as the webserver, and sometimes both are shared.
In general, it's all a matter of configuration. When you run a moderately successful small site, you're generally prepared for the amount of traffic you have, plus or minus 50%. Traffic generally grows slowly, so you have time to make adjustments when things start to get tight.
When Slashdot links your site, you get a huge influx of traffic to a site that is designed to handle a tiny fraction of that traffic. It leads to badness.
It's like trying to put an elephant into your freezer. If you're prepared for it, you have a big walk-in freezer. But most sites only need a small half-height fridge to keep their beer cold.
this is a sig.