christmas lights

Slashdot Effect Analysis on 2003 Christmas Lights and Webcam

The Christmas Lights & Webcam were humming along just fine until 1147 on Saturday, December 20th, 2003. At that minute, traffic increased a LOT; an article had been posted on Slashdot ( that had pointers to the Christmas stuff. Slashdot bills itself as "News for Geeks" ... so imagine thousands of Geeks hitting your web site, all at the same time! ;-) This Slashdot Effect can bring the computer/ISP to "its knees" as it is basically a DDOS - Distributed Denial of Service ... which is what happened in Xmas/2002 - not only did the web server melt down, but a 40 amp circuit breaker providing power to the server popped on Christmas Day - yes, this really did happen!

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, whereas the "analog" stuff does not - you have to infer problems/breakdowns due to heavy load indirectly. And the real-world analog stuff just isn't that fast, nor as "reliable", so I had coded things intentionally with a 5-second throttle with the hope that the analog side would not get overloaded - I never did pop a circuit breaker!

Here is the actual Slashdot article and comments - as typical, the signal/noise ratio in the comments are not always that high/germane. One thing that complicates the Slashdot Effect Analysis is that there were 6 URL's referenced in the posting, with one of these being the top-level ... and all of the analysis below is ONLY the Xmas related stuff - rest assured the rest of the website got hammered pretty well too! The peak hourly rate for the entire web site was 62,924 hits between 1200-1300 ... a LOT more than I typically see, but certainly not bazillions of surfers/hits, like say the Mars lander. From a bandwidth point of view is I don't have any files/images over a MByte, and the vast majority are less than 100 KBytes.

The "good" news about the story hitting at 1147 is that the webcam was not active until 1700, although the software does provide a variety of analog data (mostly weather related) via various X10 sensors. A few spot checks of these showed they all continued to provide reasonable data. Things got a little bit more interesting at 1700 when the webcam (and webcontrol - i.e. turn the lights ON & OFF) became operational ... ;-)

BTW, another "big blog/news" site is Fark ... story never made the front page of that, but it might have been interesting to see what this coulda done ... i.e. who is more "powerful" - Slashdot or Fark? Maybe that question will be answered at Xmas/2004!

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

See if I can better analyse and optimize the X10, Webcam, and other "analog" devices. I mentioned this in the what's new for Christmas/2004. The web interface enforces a 5-second throttle on web surfers, since in the "real-world" things take time - i.e. you can't move/zoom the webcam instantaneousely, and X10 isn't the fastest in controlling lights. In hindsight, the 5-second throttle was perhaps a bit conservative, although it does take a bit of time for the webcam to pan, zoom, and then snap the picture - so I don't think I "confused/blew out" anything on the analog side of the setup. But you kinda lose the effect of controlling the webcam and turning the lights ON & OFF if you are continually battling other people for control of the webcam/lights ... and with the 5-second throttle, you are limited to a maximum of 720 updates/hour ... and the peak rate was over 10 times that. It will never be possible to change the lights 238 times in a single minute, but I'd like to see if I can reduce that 5 second throttle down a bit and still have everything "work" - i.e. maybe as frequent as able to do everything in a second. The biggest challenge will be the webcam - will have to talk to my friend in the digital imaging business to see what he can get me - I've opted for best image quality in the past, but a new design goal will be raw speed with a goal of being able to update to update once/second! BTW, I highly doubt I'll ever stream video - this is just WAY too bandwidth intensive.

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. The first referral was at 1129:06 (, but interestingly enough, there were only 13 unique referral IP addresses between then at 1147:16 ... at which point, the s*it hit the fan (1,024 referralls in the next 13 minutes, with that rate pretty much sustained the next hour, and then tailing off). This does suggest that the ratio of paid/free readers of Slashdot may not be that high - i.e. not many people reading the news in the future! BTW, those numbers above are initial referrals - the total number of hits were MUCH higher (see below) as people then then cruised the web site.

Insights into the Fark subscription program - Total Fark. Another well known news/blog site is which, similar to Slashdot, is a free site, but also offers a premium "pay" service which among other things, allows you to see ALL submittals, not just those that are approved. The Analog Web Server Report showed that there were 76 referrals from, which means that a story about it WAS submitted, but it wasn't approved for Fark - guess those guys don't like Christmas, eh?!? ;-) Note that the subscription model is a bit different - in the Slashdot example, there was a 18 minute time window when I could "detect" Slashdot subscribers, whereas for Fark, the time window is basically infinite. But we can kinda compare Apples to Apples, and using the same 18 minute time window, there were 13 referrals from totalfark starting at 2045 on December 10th ... and it must have been submitted again at 1556 on December 23rd as there was then 7 referrals in the next 18 minutes from that.

How many slashdot'ers like Christmas ... and how many total Slashdot readers are there? Another interesting tidbit is despite there being 5 Xmas related URL's in the posted story, of the 20,864 referralls, there were 16,907 unique IP addresses - Slashdot'ers don't click on all the links. This suggests an upper bound on the number of Slashdot readers who actually found the story interesting enough to click thru one of the links. It may also say something about how many total folks read Slashdot. I.e. assume 10% of folks clicked through, this would imply a readership if 170,000. In fairness, maybe Christmas Lights/Webcam doesn't rock everyone's socks ... and it was a Saturday before the holiday's, so the readership may have been down. BTW, I know that the same person can end up with different IP's (DHCP/proxies/etc.) so this is not an exact count by any means, but a ballpark.

Which is "stronger" - Slashdot or Fark? Can't determine that based on the data above - plus the Christmas Webcam didn't show up to Fark ... but maybe we'll find out and do an analysis in Xmas/2004! ;-)

Alek had Google Adsense running - did I "clean up" from all the Slashdot traffic? One person asked me if I made a much money from the Google Adsense ads that are on the site. Unfortunately, the Terms of Service do not allow you to disclose (basically) ANY information. But as you are only paid on click-thru's, not ad impressions. So while the later went up by (a LOT!), the click-thru percentage (no surprise) plummented, and lets just say that the net "dollar delta" allows me to go out to a not-very fancy dinner, but probably not a movie. Adsense is a cool program (those Google guys are smart), and while I'm sure others are making lotsa money with it, I do it to basically just pay the ISP bills and just general playing around.

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.. Here is what the Perl code might look - about as "tight" a loop as you can get:
   if ( -e "$throttle_file") {
      $throttled = "YES";
   } else {
      open(FILE_THROTTLE, ">$throttle_file") || warn "Can't open $throttle_file for write: $!";
      print FILE_THROTTLE "$browser{'ip'}\n";
      $throttled = "NO";
But there is an ever so slight window of opportunity where the second person can check for the existance of that $throttle_file BEFORE it gets created. flock is your friend - here's the actual snippet of Perl code from the xmas_webcam:
   if ( -e "$throttle_file") {
      $throttled = "YES";
   } else {
      open(LOCK_THROTTLE, "$dir_locks/throttle") || warn "Can't open $dir_locks/throttle for write: $!";
      if (flock(LOCK_THROTTLE, 2|4)) {   # Exclusive write, non-blocking
         open(FILE_THROTTLE, ">$throttle_file") || warn "Can't open $throttle_file for write: $!";
         print FILE_THROTTLE "$browser{'ip'}\n";
         $throttled = "NO";
      } else {
         print STDERR "xmas $program actually had an flock fail with $throttle_file at $date_time ...\n";
         $throttled = "NO";
Note the non-blocking flock ... unlike say, an impending database write, there isn't anything compelling and we don't want to block, so if it fails, we just go ahead and say you are throttled. This actually happened 9 times - those were: 2003_12_15_12:44:55 2003_12_20_12:16:00 2003_12_20_16:56:47 2003_12_20_19:01:00 2003_12_20_19:30:01 2003_12_20_20:13:10 2003_12_20_20:41:00 2003_12_20_23:57:01 2003_12_21_22:29:18

Before anyone asks, I did NOT use the Perl HiRes Module to get sub-second accuracy - didn't feel it was neccessary and didn't want to have the overhead of pulling it in ... although note that the webcam timestamps the images in hundredth of a second. One final thought - the peak rate for JUST the CGI perl script was 11 times/second; this is pretty darn fast for my little 'ol web server that I maintain as a hobby (note that the total web server hit rate was probably about 10 times this) - this is probably "slow" for some of the "big boys" who also have to handle much more complicated transactions and really insure they are done correct - think about that next time you are booking an airline ticket online.

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 use this page to send me an Email.

Summary Data - also see the 2003 summary stats page

For 2003, the Web Server was a 2.4 GHz Xeon with a GByte of RAM and ISP connectivity was (basically) a T-3. The OS is RedHat Linux running the Apache Web Server, and I used the Analog web log analyzer to analyze the web logs. Webcam code is a couple thousands of lines of home-grown Perl code. "analog" stuff includes 3,000+ Xmas lights, a number of X10 appliance modules, a webcam capable of doing pan/tilt/zoom which shoots 640X480 images, and assorted other stuff - read more about it in the Christmas FAQ. In addition to the raw Apache Web Logs, the christmas webcam CGI program has extensive logging that correlated well with the Apache logs - a good sign right off the bat that we didn't overload the digital side of things.

Here is a summary of the Analog data from the Apache Web Server Logs:
    388,851  Total Christmas related Web hits
    135,943  Total Christmas related Page Views
  6,680,000  KBytes of Christmas related text and images transferred
     67,871  Hits on the Christmas Webcam 
     16,069  Hits on the xmas & christmas lights main page
     20,864  Referrals from Slashdot
      1,461  Referrals from Google
      1,006  Referrals from - who said my lights were ugly?!?   ;-)
	865  Referrals from - and they are not ... too ... weird either!

Here is the data as recorded from the Christmas Webcam itself (webcam controllable from 1700-2400):
     67,579  Total christmas webcam accesses (darn good correlation with Apache log data)
     38,929  Most webcam accesses in a single day - December 20th (After Slashdot)
      1,425  Most webcam accesses in a single day - December 03rd (Before Slashdot)
      7,567  Most webcam accesses in a single hour - 1700-1800 on December 20th (After Slashdot)
	274  Most webcam accesses in a single hour - 2300-2400 on December 13th (Before Slashdot)
	238  Most webcam accesses in a single minute - 1702 on December 20th (After Slashdot)
	 14  Most webcam accesses in a single minute - 2242 on December 13th (Before Slashdot)
	 11  Most webcam accesses in a single SECOND - 1700:08 on December 20th (Slashdot'ers were waiting!  ;-)
     17,662  Number of time webcam was accessed within the 5 second throttle by more than one web surfer
     21,801  Different/Unique IP addresses that accessed the webcam (2,068 were unresolveable)
	184  Non-proxy hostname that hit it the most - - this guy must like Christmas Lights!  ;-)

	 83  Total different countries that accessed webcam - had very cool geolocation stuff working
     48,214  Total hits from United States
      5,373  2nd most popular country - Canada
      2,328  3rd most popular country - Australia

      7,919  Total "ACTION" requests to turn some/all lights ON/OFF
        533  Turn ALL lights OFF (most popular change)
        398  Turn ALL lights ON
      8,720  Total "ACTION" requests to pan/zoom webcam
        362  Pan Right (most popular change)
	229  Pan Left
      1,134  Move webcam to one of the "targets"
	380  Most popular target - "Burnt Out!"
     14,025  Different/unique images served up by xmas_webcam (some images are cached/re-used)

Go back to the main slashdot effect analysis page.