christmas lights

Slashdot Effect on 2004 Christmas Lights Webcam and Hoax Revealed

Shortcut to the table below ... but some of my comments are pretty interesting since it turns out that if you want to know if a story is coming your way from sites such as Slashdot, Fark, or even the Wall Street Journal, it's possible to do so without much effort.

I once again put out my christmas lights in 2004 which seem to be fairly popular as numerous sites have picked up on. I actually think I might stand a chance against the Slashdot horde this time as I have converted to using mod_perl on the web server and have improved/optimized the Analog interfaces - see what's new for Christmas/2004 - Update: /. kicked my a** when the article first hit and I had to disable the webcam for about 90 minutes, but it was up after that! BTW, a /. reader recommended setting KeepAlive=no and this appears to make a BIG difference for me - the web server held up just fine to higher sustained load a few days later from the AP story that went National ... so thank you Slashdot! ;-)

For those that don't know, Slashdot is the incredibly popular "News for Nerds" site and can bring a thundering herd of surfers to your site, all in a very short amount of time. I've written about the slashdot effect before - I did writeups for Christmas 2002 & 2003 and Halloween 2004 ... but this can generically apply to other sites that generate a lotta traffic which can result in a DDoS - Distributed Denial of Service.

The Web Server (a 2.4 GHz Xeon with a GByte of RAM running pretty standard Linux with the Apache web server) generates copious logging data and one can use the raw data to "track" traffic from sites that link to you based on what is called the referrer (which spammers sometimes spoof for referrer log spamming) - I actually use this to do a customized body alert="message" from certain sites, so some folks were amazed I "knew" about it so soon! ;-) It's actually quite easy to see when these sites posted about the Christmas stuff because there is a very noticeable uptick in traffic - all times are Mountain Standard Time (GMT-7) and the numbers below are definately LOW because some browsers block the referrer. In date/time order, we have:



Number of inbounds per site after being posted

Site - Time Posted 5 Min 10 Min 1 Hour 2 Hours 4 Hours 8 Hours 24 Hours 2 Days Week Month Site - Time Posted
MajorGeeks - 1/2017 9 12 66 117 196 289 1,224 1,670 3,260 7,658 MajorGeeks - 1/2017
USA Today - 2/0806 8 15 83 151 318 507 840 982 1,275 2,108 USA Today - 2/0806
WeirdLinks - 3/0855 7 10 46 81 159 313 652 1,048 2,342 3,155 WeirdLinks - 3/0855
Gorilla - 6/1333 3 5 63 126 244 470 845 1,187 1,909 2,361 Gorilla - 6/1333
Ernie - 7/1520 26 60 302 607 1,343 2,364 4,941 8,320 14,680 18,654 Ernie - 7/1520
Inquirer - 11/0312 19 42 250 457 760 1,421 3,072 4,094 7,714 10,190 Inquirer - 11/0312
Heise - 11/1032 75 192 996 1,584 2,393 3,328 6,202 9,882 10,217 10,696 Heise - 11/1032
Slashdot - 12/1749 781 1,604 11,699 21,651 35,895 53,720 90,607 94,830 98,054 117,210 Slashdot - 12/1749
Aunty - 13/0503 3 5 20 42 82 174 516 1,558 2,804 4,621 Aunty - 13/0503
Yahoo - 14/1715 26 74 262 461 832 1,357 5,617 6,746 7,361 10,456 Yahoo - 14/1715
AP*1 - 14/1715 55 163 1,489 2,874 6,144 11,131 85,505 140,707 N/A N/A AP*1 - 14/1715
9News - 14/2217 263 290 492 622 714 1,026 7,754 8,190 9,236 9,900 9News - 14/2217
Norway - 15/1336 6 10 42 173 374 455 2,880 5,279 7,492 7,637 Norway - 15/1336
SeattlePI - 15/1401 26 49 371 660 1,347 1,760 1,812 1,865 1,952 2,193 SeattlePI - 15/1401
Index.HU - 18/0901 8 21 191 375 701 1,178 2,162 3,184 3,266 3,279 Index.HU - 18/0901
MBnet.FI - 19/1209 17 53 263 533 979 1,155 3,096 4,174 5,431 6,368 MBnet.FI - 19/1209
NY Times - 20/0943 2 3 12 36 68 105 182 228 340 871 NY Times - 20/0943
Canada.Com - 22/2218 1 3 12 27 37 66 328 382 499 791 Canada.Com - 22/2218
UserFriendly - 24/0100 11 18 92 178 298 705 1,447 1,473 1,557 1,619 UserFriendly - 24/0100
HOAX REVEALED HOAX REVEALED
ABC7 - 27/1419 8 19 944 1,964 3,973 5,660 7,998 8,152 8,192 8.194 ABC7 - 27/1419
WSJ - 27/1425 15 30 148 301 498 936 2,199 2,797 3,068 3,336 WSJ - 27/1425
Secondary /. - 27/1618 178 424 3,261 5,478 8,192 11,100 16,166 16,705 17,090 18,539 Secondary /. - 27/1618
FARK - 27/1822 502 1,062 5,750 10,275 16,181 21,804 33,732 35,069 35,741 36,105 FARK - 27/1822
Yahoo - 27/2057 6 11 39 82 133 187 2,796 2,940 2,965 3,002 Yahoo - 27/2057
FOX - 27/2328 9 20 84 152 411 4,430 21,501 21,716 21,785 21,802 FOX - 27/2328
USA Today - 28/0218 4 7 16 20 52 252 1,367 1,760 1,818 1,862 USA Today - 28/0218
Inquirer - 29/0336 18 28 130 288 607 1,059 1,795 2,173 2,306 2,412 Inquirer - 29/0336
NY Times - 30/0615 1 2 13 27 59 101 172 211 416 550 NY Times - 30/0615
Site - Time Posted 5 Min 10 Min 1 Hour 2 Hours 4 Hours 8 Hours 24 Hours 2 Days Week Month Site - Time Posted
*1: As noted above, AP data is all hits to main page from ALL sites, so methodology is different and not directly comparable (so not much sense in showing week/month data) ... but still kinda interesting.

Some General "Slashdot Effect" Commentary

While numerous folks have written about the Slashdot Effect, this was a little different in that not only was it a test of "digital" stuff like the web server, ISP bandwidth, Perl/CGI code, but also "analog" stuff as the code has interfaces to various sensors and the webcam itself, plus you are turning a lotta lights ON & OFF - it certainly provided one heck of a light show for the neighbors! ;-)

It should be noted that the "digital" stuff has extensive logging (as did the the webcam daemon) but "analog" stuff does not. So I don't "know" if something goes wrong (for instance, sometimes the images just come back "bad") and you have to infer problems/breakdowns due to heavy load indirectly. Plus real-world analog stuff just isn't that fast, nor as "reliable", so I had coded things intentionally with a 1-second throttle with the hope that the analog side would not get overloaded - as of 12/8, I haven't popped a circuit breaker yet, but I did have one inline light fuse pop and take out 6 strands of 900 lights (yea, I know, only connect 3 strands togather) ... but hey, when you have 17,000 lights, it probably wasn't even noticed! ;-)

The webcam page is about 20 KBytes of HTML/CSS and the webcam image varies between 10-20 KBytes ... so from a bandwidth point of view, it's a pretty lightweight page - hey, I designed it so even dial-up'ers can use it! Pre-Christmas/2004, the several thousand lines of Perl code (plus Benchmark, CGI::Carp, Fcntl, IPfree, Socket, and Time::HiRes modules) had to be slurped in each time since it ran as a CGI_EXEC. With mod_perl, it does this once ... and some misc. ApacheBench testing showed the web server is capable of 5 times as many connections under load. My code run fairly quickly - it uses signals to communicate with the "webcam daemon", so there's a sleep loop where it waits, but that isn't CPU intensive. I also have a flag to disable real-time DNS lookups and I may consider that under extremely heavy load, as those can take some time. There's a memory leak in the webcam daemon, but since this is throttled once/second, it takes most of the night to grow to a GByte in process size, and I can just restart that.


Slashdot Effect Analysis - Misc. Interesting Tidbits/Ideas/Lessons Learned - SO FAR!

The 2004 optimization of the X10, Webcam, and other "analog" devices worked well. In 2003, I had a 5-second throttle, but I looked closely at the various operations/commands and multi-threaded it as much as possible. One easy "trick" was that the weather data is actually from the previous query (it doesn't change that fast), so I just grab that data and queue up a re-request for the next person. If the webcam (this year's non-disclosure model is much quicker) is overloaded when handling someone else (signals are blocked during this time), I just grab the previous picture and say sorry, charlie. Similar optimizations were done for the other sensors, but again, these are all farmed off in parrellel rather than doing sequentially. In order to cycle the lights on & off faster than one/second, I'll have to use a different technology than X10 since it is relatively slow. BTW, several folks have asked when I'm going to stream video and I'll consider that when someone pays for an OC-3 line to my house and my web server at the ISP! ;-)

Which is "stronger" - Slashdot or Fark? Slashdot is pretty darn strong - but Fark generated comparable traffic.

Insights into the Slashdot subscription program. While Slashdot is a "free" web site, you can pay for a subscription which also allows you to see stories earlier - i.e. beat the crowd and see into the "mysterious future" which I recommend - cheap, easy, ... and very useful when they descend onto your site. The first referral was at 1729:39 (213.152.50.6) and there was a total of 63 inbound referrals (including me!) from 43 unique IP's until it hit the publically viewable page at 1749:03 and the thundering herd showed up! ;-) Ironically, the Slashdot subscription FAQ says about 10-20 minutes early ... this was (basically) exactly 20 minutes ... just like it was for Halloween/2004.

Insights into the Fark subscription program - Total Fark. The TotalFark gang swung by a couple of times for a little over 500 referrals, and then pounded the site when it hit the main page.

How many FARK/Slashdot/Ernie/etc. readers are there? The number of unique IP's was 70-80% of the numbers above (surprisingly consistant) which is a ballpark figure for number of readers - yea, I know there are proxy, DHCP, etc. issues. As mentioned, it's hard to say how popular the Christmas webcam is for the referring web sites readers, so that certainly influences the numbers.

For the coders out there - be sure to think about and handle race conditions - they DO happen! If you have never dealt with race conditions, The Slashdot Effect is certainly a good test of your code. A classic (but flawed) approach to file locking is checking to see if a file exists, and if not, creating it ... but that is not an atomic operation - i.e. it's two different steps seperated by a small amount of time - read more in my Christmas 2003 Slashdot Effect writeup. mod_perl is also unforgiving (since your program basically runs as a subroutine within an interupt loop) ... and I had a file lock that I forgot to unlock - oooops! BTW, I use Perl Cookbook Recipe 7.11 to handle file locking and incrementing of a couple of counters - this works flawlessly ... except when Slashdot showed up in Halloween and Christmas 2004 ... oh well! ;-)

Would it be possible to get "early notification" of an incoming Slashdot? I don't log/track the referrer in real-time with the CGI Perl script, but this would not be difficult to add ... and then it's simply a matter of looking for the incoming "slashdot.org/" (main page) ... but as noted above, this would only give me 20 minutes notice. For Fark, you would look for incoming "totalfark.com" which would signal that it has been submitted, but I don't think there's any early indicator of when it has been approved except they all show up at once. Note that if I tracked this, it would be fairly easy to get/display "rate" information - i.e. 1,528 /.'ers in the last 10 minutes.


Want more info and/or have a suggestion/idea for me? The Christmas FAQ has some more info as does my responses when folks Email Santa. And if those don't answer your questions and/or if you have an idea (or just want to send me an atta-boy), then send me an Email.


Go back to the main slashdot effect analysis page.