Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
The Internet News Slashdot.org

Surviving Slashdotting with a Small Server 307

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?"
This discussion has been archived. No new comments can be posted.

Surviving Slashdotting with a Small Server

Comments Filter:
  • by sweeney37 ( 325921 ) * <mikesweeney@g m a i l . c om> on Sunday August 10, 2003 @05:41PM (#6661298) Homepage Journal
    Our little departmental server [smu.edu] has been slashdotted twice in the last year and survived!

    Wait... is this a challenge?

    Mike
    • by bad_fx ( 493443 ) on Sunday August 10, 2003 @05:57PM (#6661396) Journal
      Yeah [smu.edu] come [smu.edu] on [smu.edu] folks, [smu.edu] do [smu.edu] your [smu.edu] bit [smu.edu] for [smu.edu] slashdot's [smu.edu] reputation! [smu.edu]
    • by BWJones ( 18351 ) on Sunday August 10, 2003 @05:59PM (#6661410) Homepage Journal
      Our little departmental server has been slashdotted twice in the last year and survived!

      Oh, come on. Even my little old G3 iMac [utah.edu] is capable of handling quite a load from Slashdot and this site is serving up graphics intensive stuff. What you need to prevent a good Slashdotting is bandwidth that universities provide. T3 backbone connections are a wonderful thing. :-)

      Go ahead click all you want.

      • by Anonymous Coward
        a friend of mine had his site featured on the front page of slashdot without any problems. Page hits spiked for a couple days, but his setup (P4 x86 linux box, apache, busines DSL) handled it fine. And, after being hit he discovered his bandwidth was being capped too low by his ISP :).

        Most slashdottings come from limited bandwidth or php/perl/asp/mysql/ etc being unable to handle it. Most dynamic content could be static content. (Most slashdot pages are static caches).

        • by Syre ( 234917 ) on Sunday August 10, 2003 @09:37PM (#6662246)
          Static content is right.

          In 1998 I was working at a startup and we served Olympics news to Excite.com, which was one of the very largest sites on the web back then. Excite linked to pages on our server which were at some URL like olympics.excite.com that pointed to us.

          What they didn't know was that we were serving all this off of ONE Sun Ultra 1 workstation on my desk (which was all we could afford at the time). I had it set up with Squid so everything was coming out of memory.

          It worked fine, even at peak times everything popped up about as fast as any other page on Excite.

          Moral: if you need speed and the page doesn't really have to be dynamic make it static or cache it.
      • Re:OT (Score:3, Interesting)

        by E_elven ( 600520 )
        Well, it's 8:20pm EST and I'm not getting through from a T1.
  • by yanbusa ( 532429 ) on Sunday August 10, 2003 @05:43PM (#6661304) Homepage
    They are asking for another test.
  • Weeee.... (Score:3, Funny)

    by Ridge ( 37884 ) on Sunday August 10, 2003 @05:43PM (#6661309)
    Third time's a char... DOH!

    Heh, well they're actually still kicking, oh well, it would've been so apropos.
  • by Anonymous Coward on Sunday August 10, 2003 @05:45PM (#6661317)
    Thou shall not survive thrice. You're insolence will not be tolerated. You'll servers will suffer a slashdotting not hence seen....
    • Are you sure this is the third time? I count five...

      [Arthur, King of the Britons] One, Two, Five!
      [Knight] Three, Sir!
      [Arthur, King of the Britons] Three!
      **HALLELUIAH**
      *BooM*
  • Clever, clever (Score:4, Insightful)

    by Frodo2002 ( 595920 ) on Sunday August 10, 2003 @05:46PM (#6661321) Homepage

    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...

  • by Billly Gates ( 198444 ) on Sunday August 10, 2003 @05:47PM (#6661327) Journal
    I find it hard to believe that a cheap dual channel switch for 2 pc's could handle the slashdot effect.

    I was under the impression that a 20k fiber or 100mbs one that can dynamically shift traffic would be needed.

    • From the Article:
      Each machine has its own independent 100 Mbit connection to the Gigabit SMU internet service,

      I really didn't see 'cheap dual-channel switch' in there anywhere . . I DID see independent 100 Mbit connection though.
      • by Limburgher ( 523006 ) on Sunday August 10, 2003 @06:22PM (#6661537) Homepage Journal
        It's not the switch/throughput that's the issue. It's the amount of page generation being done by the servers themselves. The high throughput and individual links merely allows the maximum possible number of simulatneous hits from a bandwidth standpoint. The trick here is to do that, AND have your webserver survive, hence the dual box Linux Virtual Server setup. That's the piece that smells the /.ing and tries to load-balance the page generation. That ability should allow this setup to survive most /.ings.

        Very inexpensively, I might add. Beats having to buy the hardware for an, I dunno, . . .

        Beowulf cluster?

    • Assuming the page was fairly small, without lots of pictures or movies, I'd imagine that a small 10/100 switch would handle the load fairly well.

      On the stats link provided for a January slashdotting, the most bandwidth used in a day was a little under 7.4 GB. Assume that it was posted on /. at noon, so there were 12 hours to spread the big hit over: about 617 MB/hr. That's a little over 10 MB/Min, or 170 KB/sec. Even if we assume that the initial hit was double that, I can easily stream a 1000 KB/sec Divx movie over my 100 Mbps switched home LAN. The limiting factors here are the servers, routers and bandwidth to the Internet, not the local network connecting the servers.

  • well golly gee... (Score:5, Insightful)

    by JeanBaptiste ( 537955 ) on Sunday August 10, 2003 @05:47PM (#6661328)
    (also having a university-supplied BIG PIPE doesn't hurt).


    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....
    • Re:well golly gee... (Score:5, Informative)

      by Lumpy ( 12016 ) on Sunday August 10, 2003 @06:10PM (#6661478) Homepage
      nahhh... you can survuve a slashdotting much easier...

      simply use thttpd.

      it has throttling built in so that the slashdotting wont take down the server. It simply stops serving images at anything but a really slow rate and eliminates multiple requests from same hosts... (A bitch for NAT'ed companies)

      There are httpd servers out there that are much better than apache for handling insane loads.
      • Re:well golly gee... (Score:5, Interesting)

        by seanadams.com ( 463190 ) * on Sunday August 10, 2003 @06:41PM (#6661620) Homepage
        It simply stops serving images at anything but a really slow rate

        What's the point? Either way you're slashdotted.

        Besides, I think in the case of server overload (as opposed to network overload), throttling will only exacerbate the problem by increasing the number of slow clients you have to deal with. This is the #1 bottleneck in web servers, the more clients you have, the longer it takes to deal with each one of them. Losts of processes to switch between, long arrays in an out of select(), etc.

        Also, when a user doesn't get a page in his browser, what does he do? He clicks the link again and again.... even more connections to handle.

        Really the only way to cure an overloaded server is to drop incoming SYNs. Any other measure is just pouring gasoline on the fire.
      • If you want to continue serving your _real_ users while giving the slashdot crowd as much fun as you've got leftover horsepower to handle, and you're planning for this sort of thing in advance, it may help to trick your system into serving the slashdot crowd from one server and the regulars from a different one. Some obvious implementations:
        • Use the HTTP REFERER to direct /.ers to the second machine.
        • Use a friendly low-graphics front page that asks /.ers to click a link that goes to the second machine.
        • Mo
    • by mo ( 2873 ) on Sunday August 10, 2003 @06:15PM (#6661504)
      You're right. Bandwidth also serves a big purpose in finishing requests quickly. For example, let's see what happens when I have a 1.5mbps line with 512 concurrent requests. First of all, if you're using apache 1.3.X or 2.0 prefork, you've filled 2 gigs of ram by spawning 512 clients. Furthermore, you're bandwidth allocation per-client is 384 bytes/sec. This means you're spoon feeding your pages to your clients which makes it really hard for your server to get that 512 number down to something manageable.

      The problem here, is that the bandwidth bottleneck will make your server either (a) run out of processes/threads, (b) run out of ports/sockets, or (c) run out of memory from spawning all of the processes/threads to handle all of the stalled connections.

      Once this happens, people no longer can connect to you, and you're toast. The crazy thing here is that this can happen even at 10mbit/sec if you're machine is configured well enough, and if the content you're serving is large enough (IE: image/media serving).

      So cheers for these guys at keeping their bandwidth/server ratio high, I actually really like their architecture. But note that the greatest architecture in the world won't save you from a slashdotting if your server(s) are on a business dsl line.
      • Re:well golly gee... (Score:3, Interesting)

        by evilviper ( 135110 )

        But note that the greatest architecture in the world won't save you from a slashdotting if your server(s) are on a business dsl line.

        That's not true at all.

        Configure your maximum number of users to something your server/bandwidth can handle, and then send everyone else an error page that says they need to wait. That error page can automatically try to re-load the main page every 1-5 minutes, until it is successful.

        Even on your dial-up connection you could survive a slashdotting.

        • by KPU ( 118762 )
          Um sending people an error page is NOT surviving a slashdotting.
          • by evilviper ( 135110 ) on Sunday August 10, 2003 @09:37PM (#6662251) Journal
            We aren't talking about an actual error, that's just what it is called.

            What we are talking about is sending a different, low-bandwidth page, which will reload the main page after a certain ammount of time.

            Sure, you aren't immediately serving up the page to everyone who is requesting it, but people will only see a delay of a minute or so, rather than the server not serving up anyone, and crashing and burning for a day before anyone resets the thing. Or maybe just saturating the line, so nobody gets anything faster than 0.00001kbps, which is far far worse than having to leave the error page open in the background a couple minutes before it has a chance to load the main page.
    • Re:well golly gee... (Score:5, Interesting)

      by Jeremiah Blatz ( 173527 ) on Sunday August 10, 2003 @06:28PM (#6661559) Homepage
      JeanBaptiste writes:

      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....

      With static web pages, server power is rarely a problem, it's all about the pipes. However, if the pages are dynamically generated, and don't have a lot of caching, then you've got yourself a big problem.

      So take, for example, loading a forum page in UltimateBB. AntiOnline handily tells you how many db requests it takes to create a page, and how long it took. This one over here says 61 requests and .3 seconds. Now, the poster claims to be peaking at ~37000 page views/hour, which is 10 hits per second. Now in that .3 seconds, where 61 database connections were established, there were another 3 requests coming in, making it an average of 240 database connections every .3 seconds. That's not an unreasonable number of connections, but what if your DB server can't keep up? What if, due to the load, the queries take 10x longer than usual? At that point, over .3 seconds, you get 240 connections, but only service 24 of them. Over the next .3 seconds, you get another 240 requests, but service only another 24, leaving you with 436 pending. After 30 seconds, you've serviced 2400 requests, but have another 21,600 pending. before too long, you're out of possible TCP ports.

      There are ways to keep your servers from crapping out under heavy load. One is to buy a studly, fire-breathing DB server that can process requests faster than your web servers can send them. Another (cheaper) solution would be to pool and marshall your DB requests, being sure to remove requests from the queue when the remote user times out (either by clicking the stop button or running up against a built-in limit of their browser). This way, your site may get slow, but nothing will crash. A final method is to use enough caching on the web server that you pages are, essentially, static. This is, for instance, what Vignette does, which is why all the major news sites use it. This method combines the flexibility of database-backed CMS systems with the database load of static web pages.

      So, essentially, there are many ways to let your database-backed web site survive a slashdoting, but embedding a bunch of PHP SQL queries against a locally-running installation of MySQL is not one of them. Unless you have a big honkin' cluster.

      • Re:well golly gee... (Score:5, Informative)

        by Syre ( 234917 ) on Sunday August 10, 2003 @09:47PM (#6662298)
        Vignette is a rather trivial hack which was developed at C|Net and licensed to Vignette. It basically just writes out static pages, nothing fancy.

        As soon as Vignette licensed it, they were able to claim C|Net as a "Big Customer", which of course was a fib. This let them sell loads of software to organizations that didn't know any better.

        Moral of the story? Static pages are a great idea. If you can't do static easily, put a cache in front of your dynamic pages and decide how dynamic you really need them (Is 15 minutes delayed OK for you or is each page totally dynamic?). You don't need to spend $250K for Vignette to get this to work. In fact, you can do it with free software quite easily.

        Web caching and optimization is a big topic but in general the more clever you can be the less money you have to spend on big iron.
  • by Eevee ( 535658 ) on Sunday August 10, 2003 @05:48PM (#6661329)

    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.

    • LOL. So, are you saying to try again at, say, just for hypothetical purposes, 2003-08-11 16:30 GMT?
    • by Anonymous Coward
      I think that's part of it. But I bet most of the effect goes to Karma whoring. Notice the second minor blip later on in their data.

      When the article is new, the rush is on for insightful comments that deal with commenting on elements of the referenced links. (Might as well, there aren't any comments beyond ascii pictures, and troll expiditionary forces.) They have their responses, which then triggers the volley of RTFA's, and now there are a number of posts, people don't have to RTFA so much and the thre
    • Well they could, but instead of load testing the thing people would just bitch about the duplicate.
  • That hits graph (Score:4, Insightful)

    by KingDaveRa ( 620784 ) on Sunday August 10, 2003 @05:48PM (#6661330) Homepage
    Interesting how it peaks, drops off slowly then rises again a little before dropping off again. Maybe some 'behind the curve' slashdot readers?
    • or some of us who once we see the site is /.ed, wait a while before trying again. or give up since it cant be that damn important. or someone (often) posts a mirror of the /.ed article. or someone quotes it.

      there is probably more of an explanation than just a short attention span. Wait, that is what you were talking about, right? ;-)
    • A lot of "minor" news site get their stories from slashdot, and they might be a bit late. Maybe the visitors coming from these sites make up the final rise?
    • Or dupes.
  • well... (Score:3, Funny)

    by painehope ( 580569 ) on Sunday August 10, 2003 @05:48PM (#6661338)
    I've got some exponentially decaying pieces of chicken on my table...

    and some exponentially growing forms of life in some beer cans...

    does that count?
  • I only wish I had enough bandwidth to be able to test the hardware out properly.
    2Mb? It's nothing for a nice server.
  • by Anonymous Coward on Sunday August 10, 2003 @05:49PM (#6661344)
    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.
  • "Our little departmental server has been slashdotted twice in the last year and survived!"

    I hope the dupe jokes that get posted are better than what I had here before I decided to just post this in hopes of drawing better jokes later in the thread. They weren't good! But when are they?

  • zerg (Score:3, Funny)

    by Lord Omlette ( 124579 ) on Sunday August 10, 2003 @05:50PM (#6661354) Homepage
    This is almost as stupid as wearing a mask of Donald Rumsfeld and visiting 3ID troops to tell them "Are we planning on letting you go home anytime soon? Gosh, no!"

    These SMU guys are obviously begging for it, I say we give them hell!
  • by Chmarr ( 18662 ) on Sunday August 10, 2003 @05:50PM (#6661356)
    Just under 40,000 hits in the busiest day... this is a slashdotting? Come back when you get into the millions. :)
    • then again, we COULD just wget the whole damn site, delete and re-wget it again. simple "while true" script it would seem. that would tend to increase the hits at an exponential level.

      while true
      do
      wget --delete-after -m -p http://www.geology.smu.edu
      done

      or something like that.
  • Nope... (Score:5, Funny)

    by ryanvm ( 247662 ) on Sunday August 10, 2003 @05:52PM (#6661363)
    Anybody else observed similar phenomena?

    Nope. In our jobs they make us do work.
  • by twoslice ( 457793 ) on Sunday August 10, 2003 @05:53PM (#6661369)
    There is a total of 80K of information on the entire front page! Dig a little deeper guys and perhaps we can find a few gigantic image downloads. If you find any do share =)

  • by plierhead ( 570797 ) on Sunday August 10, 2003 @05:54PM (#6661372) Journal
    Nice work, but of course your amazing resilience to the multi-headed hydra that is the slashdot audience is all to do with your BIG PIPE and nothing much to do with your dual headed linux configuration.

    While your setup may make you real safe from machine outages, the effects of a slashdotting are to flood your resources rather than break them. So your configuration gives you at best the performance of two machines instead of one - which you could also have achieved by just ramping up the CPU or memory.

  • by siberian ( 14177 ) * on Sunday August 10, 2003 @05:54PM (#6661374)
    Its incredible, this person has actually proven that LOAD BALANCING MULTIPLE SERVERS INCREASES YOUR LOAD CAPACITY! This is incredible news! Wow, I am sure glad it made it as an article, stunning.

    Every medium to large website out there will be pleased to know that what they have been doing for the last 8 years is actually VALID, thanks guys!

    I think the only reason this made it to the front page is the slashdot self-reference.
  • Eleventh Post (Score:3, Insightful)

    by fm6 ( 162816 ) on Sunday August 10, 2003 @05:54PM (#6661376) Homepage Journal
    The first ten all make the same lame joke. Get a life people!
    More interesting is the documentation of the apparent exponentially decaying attention span of slashdotters.
    I'm not sure the decay fits any simple math model. Here's a more practical explanation: It takes about 24 hours for a Slashdot story to scroll off the main page. So for the first day and part of the second you're getting hits from every slashdotter. After that you're only get hits from people who compulsively look through old stories and/or browse Slashdot through RSS feeds and other offline tools. And after that, of course it's old news.

    I'll bet if you chart the data hour-by-hour, you'll see a sudden dropoff at the very moment the story scrolls off.

  • I always figured the majority of slashdotting occured because of bandwidth constraints. I suppose a few servers crapped out, but that has got to be few and far between, hasn't it?

    Don't let me crap all over your cutesy linux saves the day story, though.
    • Its definitely bandwidth. ticalc.org, which has always had a puny server, has survived several /.'ings thanks to its large, large pipe.

      That and intelligent site design. Most of the pages on ticalc.org (most =~ all) are pregenerated.

      --
      lds
  • decay pattern (Score:3, Interesting)

    by tomdarch ( 225937 ) on Sunday August 10, 2003 @05:57PM (#6661391)
    I'm surprised that there was so much traffic on the second and third days (given that stories drop off the front page)

    It's also interesting that there was a second little bump about a week later. Anyone have any ideas why?

    • I think the article mentions something aboot a TV press conference / media attention about their recording of the seismics of the event, plus wasn't the explosion on a Saturday? Those without the net at home would undoubtedly surf for the event on Monday.
  • by 0x0d0a ( 568518 ) on Sunday August 10, 2003 @05:57PM (#6661395) Journal
    You didn't get Slashdotted if the server was still operating normally. You just had some people from Slashdot visit.
  • More interesting is the documentation of the apparent exponentially decaying attention span of slashdotters.

    I think this is why Slashdot makes you wait 20 seconds before you can submit a comment. They figure this will weed out 80% of the responses as the people get bored of waiting for the 20 seconds to be up and they just leave.
  • by captainboogerhead ( 228216 ) on Sunday August 10, 2003 @05:58PM (#6661404) Journal
    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?
    • It's really a combination of bandwidth, hardware & apache configuration. A T1 or higher link, fast enough processor (or SMP system) with 512 MB RAM or more & a decent apache configuration (sorry I'm not on Linux right now, or I'd be more specific) should be enough to survive a slashdotting.
  • Since they seem to think they can handle the slashdotting, I've taken the liberty and searched through their site. This page [smu.edu] has a number of links to pages which have large images and movies linked to. Hopefully, this will really provide them some load.
  • Pretty simple... (Score:5, Interesting)

    by seanadams.com ( 463190 ) * on Sunday August 10, 2003 @06:00PM (#6661419) Homepage
    My server [seanadams.com] 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 [slimdevices.com], I moved the main server up to a colo [he.net] 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.
    • There's a widespread misconception here that slashdotting is caused by server overload. In reality this is almost never the case.

      It's more likely to be server overload here than anywhere else, don't you think?

      Dear Slashdot,
      I just installed a webserver on my Gameboy. Would you please turn it into a smoldering hole in the ground?

      Thanks!


      Also, with a little smarts from the server, you can prevent bandwidth overload. All you really need is to limit the number of concurrent users that can be connected to

  • by Anonymous Coward
    Add / to directory URLS, that will avoid a 301 redirection (/foo -> /foo/).


    BTW, using static pages also helps too. What is more, the "how to not survive" includes "generate content dynamically every time".

  • OK Mr. Tough Guy, put a database on the backend and serve up some dynamic content. Then we'll see if you can really survive a slashdotting.
  • by Titanium Angel ( 557780 ) on Sunday August 10, 2003 @06:04PM (#6661434)
    More interesting is the documentation of the apparent exponentially decaying attention span of slashdotters. Anybody else observed similar phenomena?"
    Actually, yes. Stephen Adler did an analysis [bnl.gov] of the /. effect, where you can see similar graphs. It's not surprising, really.

    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?
  • by Mish ( 50810 ) on Sunday August 10, 2003 @06:06PM (#6661449)
    They're just begging for a 'real' test... ... such as everyone downloading this:

    ar405eng.exe [smu.edu] (5.41 MB)

    from their webserver :p

    5.41MB per slashdot reader should provide a test worth of such a fat pipe ;)
  • I know... (Score:3, Funny)

    by Dark Lord Seth ( 584963 ) on Sunday August 10, 2003 @06:09PM (#6661469) Journal
    More interesting is the documentation of the apparent exponentially decaying attention span of slashd

    Huh? What?

  • by localroger ( 258128 ) on Sunday August 10, 2003 @06:15PM (#6661500) Homepage
    Yeah, I noticed that too [kuro5hin.org].
  • Attention Span (Score:5, Interesting)

    by cmacb ( 547347 ) on Sunday August 10, 2003 @06:16PM (#6661506) Homepage Journal
    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.
  • Mirrors (Score:3, Insightful)

    by brejc8 ( 223089 ) * on Sunday August 10, 2003 @06:17PM (#6661510) Homepage Journal
    The ideal situation would be if you got a warning from slashdot and then then made some mirrors of the pages on distributer mirror [wolffelaar.nl].
  • by SerialHistorian ( 565638 ) on Sunday August 10, 2003 @06:20PM (#6661525)
    ...a glutton for punishment!!! Either that, or they want to test it some more. Do your worst, slashdotters!
  • They don't get charged for web bandwidth by the gigabyte. :-P
  • More detail, please (Score:5, Interesting)

    by embobo ( 1520 ) on Sunday August 10, 2003 @06:30PM (#6661567) Homepage

    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?

  • by MBCook ( 132727 ) <foobarsoft@foobarsoft.com> on Sunday August 10, 2003 @06:33PM (#6661581) Homepage
    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.
  • by Jahf ( 21968 ) on Sunday August 10, 2003 @06:35PM (#6661591) Journal
    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.

    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 ... 2 hours for full distribution is going to be friendlier to the /.ed sites, but 1 hour total would probably still be effective.

    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 /.

    • The problem with that is by giving a heavy disadvantage to the newest user on the system will likely make that new user feel unwelcome. That leads to abandonded newbie accounts, which is a bad thing for business. If you have no replacement customers coming in for the ones who leave, you'll have a decaying site and there won't be any /. effect anymore, nor will there be a /.

      Beware of side effects when you try to implement simple solutions like that...
  • Exponential decay (Score:5, Insightful)

    by rjh ( 40933 ) <rjh@sixdemonbag.org> on Sunday August 10, 2003 @06:46PM (#6661650)
    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?
  • by jazman ( 9111 ) on Sunday August 10, 2003 @06:55PM (#6661682)
    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.

    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 /.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.
  • by niko9 ( 315647 ) on Sunday August 10, 2003 @07:17PM (#6661767)
    Taco:Yes, of course! The Holy Slashdot of OSDL! 'Tis one of the sacred relics Brother Cowboy Neal carries with him. Brother Neal! Bring up the Holy Slashdot!

    AC's chanting: Pie Iesu domine, dona eis requiem.

    Brother Neal: Armaments, chapter two, verse nine to twenty one.

    Brother Neal: And Saint Cowboy Neal raised the Slashdot up high, saying, 'O Lord, bless this Thy Slashdot that, with it, Thou mayest slashdot Thine enemies to tiny bits in Thy mercy'. And the Lord did grin, and the AC's did feast upon first posts, trolls, GNAA posts, and...

    Taco: Skip it a bit, Brother.

    Brother Neal: And the Lord spake, saying, 'First shalt thou click on the holy link called Slashdot. Then, shalt thou count to three. No more. No less. Three shalt be the number thou shalt count, and the the number of the counting shall be three. Four shalt thou not count, nor neither count thou two, excepting that thou then proceed to three. Five is right out. Once the number three, being the third number, be reached, then, clickest thou holy Slashdot of OSDL towards thy server, who being naughty in My sight, shall snuff it.'

    Taco: Amen
  • by QEDog ( 610238 ) on Sunday August 10, 2003 @07:38PM (#6661824)
    "exponentially decaying attention span of slashdotters"

    It is called Geek A.D.D.

  • by NerveGas ( 168686 ) on Sunday August 10, 2003 @07:50PM (#6661852)

    The guy is talking about bursts of 42,000 hits per day, and talking about it "bringing their system down". Now I could see that on Windows, but not on Linux.

    Now, before you think I'm talking out of my posterior orifice, when my company was young and bright, we had a server built on a single 450 MHz Pentium 2, and 256 megs of RAM. It ran both Apache and PostgreSQL. Many of our pages were database-driven, which of course is a much larger load on the server than simple static pages.

    That little machine would peak out at around 60,000 hits per day. At that point, it was slow enough to be self-limitting, but there was never any fear (or realization) of having the machine "brought down".

    So, still "back in the day", I replaced it with a dual P3/650. That machine would peak out at around 100,000 hits/day (database driven!), without much problem at all. Also, as time goes on, and we develop new apps that make further use of our data, we tend to need more power to generate every page. Even still, we could crank out 40,000 hits per day on what would now be a relatively anemic server.

    Now, with 7 front-end web servers and a dedicated DB machine, we crank out 5 million hits/day without problem. And even when our systems have been IMMENSELY overloaded from both legitimate and illegitimate traffic, the systems have still responded, and never once have I ever worried about a machine "going down" from the load. Failed hardware, perhaps, but not the load.

    steve
  • by Lord_Dweomer ( 648696 ) on Sunday August 10, 2003 @10:00PM (#6662366) Homepage
    I don't know much regarding the technical details of this, so pardon my ignorance, but why is it that Slashdot never gets slashdotted?

    • by limbostar ( 116177 ) <stephenNO@SPAMawdang.com> on Monday August 11, 2003 @02:40AM (#6663457) Homepage
      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.
  • ha! (Score:3, Interesting)

    by rabtech ( 223758 ) on Sunday August 10, 2003 @10:15PM (#6662431) Homepage
    my server survived a slashdotting just fine - IIS 5.0 / win2k sp3, 512 ram, single IDE HDD, P3-800mhz, etc.

    The problem was, as it is for most people who get slashdotted, I didn't have a big enough pipe. Nothing to be done about that. I can't afford an OC3.
  • Bah (Score:3, Insightful)

    by ttyp0 ( 33384 ) on Sunday August 10, 2003 @11:01PM (#6662625) Homepage
    No need to throw lots of hardware and redundant systems to survive a /. From what I've seen, most sites that go down are due to a small number of reasons:

    1. Not enough bandwidth
    2. Poorly configured web server
    3. 300k images & 20MB mpeg/avi downloads (see #1)
    4. Not enough RAM (1GB is generally enough)

    I host about 50 domains for friends on my webserver (an Athlon 1.2Ghz w/ 1GB RAM) and have survived a simultaneous Slashdot and Fark link.

    --Brent

    Anti SCO T-Shirt [antitshirts.com]

When the bosses talk about improving productivity, they are never talking about themselves.

Working...