I’ve always wondered if most hosting companies even care about supporting their customers when traffic surges hit. A recently Dugg article “How Not To Deal With A Digg” makes it worth revisting those thoughts and putting up a bit of math to support that shared hosting companies are concealing a lot behind the bandwidth they offer in their packages.

Just like most gyms sell memberships to more people than could fit into the workout area if all those members showed up once per day, many hosting companies price their packages at levels that are only profittable if traffic stays very low. In the Seminal’s article, referenced above, they started with a shared web hosting package from iPowerWeb. That package offers 2,000 GB of bandwidth for $8/month - and I’m going to stay focused on that number because bandwidth is the number one place where shared web hosting companies fail to deliver on their promises (plus an 800mhz Pentium 3 with 1 GB RAM webserver that I run at work delivers 10-15 GB/day of web traffic for an application we only use internally, so the meagre specs on that hardware work fine for 275 GB/month [conservatively, 12.5 GB/day for 22 work days each month] over 100 mbps & 1 gbps network connections). A good price for bandwidth, for a hosting company leasing multiple OCx-class connections, is about $0.06/GB. That means that 2,000 GB of bandwidth works out to $120/month. In fact, your $8/month is only enough to pay for about 133 GB of bandwidth before the hosting company starts dropping into the red.

Yikes! The truth is there’s no way those lower-end hosting companies can make money from basic web hosting packages if even a small percentage of their clients are using a good chunk of the allotted bandwidth. It’s true that the numbers presented in the hosting package descriptions are typically loss-leaders, but the packages and services offered by any hosting company should be capable of reaching what they’re rated to. And, if the high bandwidth usage is a problem thsn companies should either ask users causing them a loss to leave (which sure would get those companies a lot of attention on Slashdot and Digg) or they should also institute and disclose a rate-cap of how much bandwidth/second can be used (for example: 2,000 GB/month over 2,592,000 seconds for a max rate of ~768 KBps).

In my experience of content sites’ daily traffic patterns, most non-rich media websites see averaged daily traffic rates that are only 5-15% of their peak daily rate. Let’s assume that a front page link from Digg will only triple your normal peak rate of visits (unlikely) and then work backward from 768 KBps to see what a realistic monthly usage would be from one of those shared hosting packages. One third of 768 KBps is 256 KBps, which represents our peak daily traffic rate when not featured on a big, linking site. Take 10% of that and get 25.6 KBps, or 26 KBps if we round to keep things clean. 26 KBps times the 2,592,000 seconds in a 30 day month is 67,392,000 KB of data, or ~67.4 GB/month when we’re talking in the same terms as those hosting plan providers. That seems more reasonable at a rate of $0.06/GB for an $8/month web hosting plan. Now only about $4/month goes to pay for bandwidth and the rest can pay for the hosting providers servers and staff.

Before we forget the whole point of this, 768 KBps means that an average content site with a 250 KB front page, JS, CSS, and images will take about 1/3rd of a second to transfer. Add another half second of latency, I know average latency isn’t that high but the server and browser take a little while to deal with each individual HTML, CSS, JS, and image to be transferred, and the total page load time is about 5/6ths of a second. Now grab this Browser statistics Firefox extenstion and check your own shared host website. This site has a 156 KB page load, is happily hosted on a 1and1 shared server, and has a 4.5 sec. average page load time and 1.8 sec. minimum page load time according to Google’s webmaseter tools and the large number of page loads their spider does of this site. Odds are you’re looking at a download time a lot higher than 5/6ths of a second. If that’s the case then how can your shared webserver ever stand up to the traffic experienced when being Dugg or Slashdotted?

Plain and simple, that shared web server won’t cut it when you’re Dugg or Slashdotted. The artificial statistics I’m using above, of 768 KBps peak and 26 KBps sustained, make it clear that shared host webservers aren’t capable of profittably delivering the 1,000+ GB/month that most of them advertise. Real world page load times indicate that most shared hosting companies can’t realistically sustain a 768 KBps peak rate or 67 GB/month of traffic to your site. All the caching and HTML/CSS-tweaking in the world won’t save a website when it still has to get squeezed through a skinny pipe.

Sadly, many shared hosting companies are generally happy save money offering poor service and then by allowing higher bandwidth users (costing them $0.06/GB) to move elsewhere. I really hope this practice goes the way of selling CRT monitors based on the tube size instead of the viewable size. Since I’m not a fan of government regulation, I hope some of the bigger or higher-quality shared hosting companies start offering throughput guarantees to compete with the cheap shared hosting packages that can’t deliver.

The Recovery Console is an incredibly powerful tool at times when a Windows system boots straight into a blue screen (of death) error or viruses/spyware have even made the system unusable in safe mode. Unfortuantely it’s hard to use for several reasons. Firstky, Microsoft doesn’t, to my knowledge, provide complete documentation for the Recovery Console anywhere. Also, the Recovery Console is a command-line-only interface that’s unfamiliar to most Windows users and even many non-Linux IT staff. Finally, the commands available in this environment are fewer and slightly different from those in a typical Windows shell environment.

This site, Command Windows, provides a complete list of the available commands with a description of each. Also included is documentation on some preventative measures (as usual, registry edits) that can be taken before Windows crashes to remove some of the restrictions on the Recovery Console later on. The restrictions that can be removed include disallowing Recovery Console from writing to a floppy disk, blocked access to some system folders, and not being able to use wildcards on the command line.

Setting up email for home users always ends up being a messy and long “quick fix”. Just in case the DSL accounts docs get lost (doesn’t everyone lose their documentation first thing?) - here’s a list of SMTP (outgoing) email servers for many major ISPs, updated June 2005. Nonetheless, the best bet for home user setups is to print POP, SMTP, and other settings before heading to the job.

• Adelphia: mail.adelphia.net
• Ameritech: smtp.ameritech.yahoo.com
• AOL (America Online): smtp.aol.com
• Atlantic Broadband: smtp.atlanticbb.net
• AT&T: mailhost.att.net
• AT&T Broadband: mail.attbi.com
• AT&T Global Dialup: smtp1.attglobal.net
• AT&T Worldnet: mailhost.worldnet.att.net or imailhost.worldnet.att.net
• BCPL: mail.bcpl.net
• Bellatlantic: gtei.bellatlantic.net or smtpout.verizon.net
• Bellatlantic.net: smtpout.bellatlantic.net
• Bell Canada: smtp10.bellnet.ca
• Bellsouth: mail.bellsouth.net
• Bestweb: smtp.bestweb.net
• Blazenet: smtp.blazenet.net
• CableOne: mail.cableone.net
• CAIS: smtp.cais.net
• CAPU: smtp.capu.net
• Charm.net: smtp.charm.net
• Charter Communications: smtp.chartermi.net
• Charter.Net: smtp.charter.net
• CharterMI.net: mail.chartermi.net
• CharterTN.net: mail.chartertn.net
• Coax.Net Central: smtp.central.coax.net
• Coax.Net East: smtp.east.coax.net
• Coax.Net West: smtp.west.coax.net
• Comcast: smtp.comcast.net
• Compuserve: smtp.compuserve.com or smtp.site1.csi.com
• Concentric.net: smtp.concentric.net
• Covad: smtp.covad.net
• Cox West: smtp.west.cox.net
• Cox Central: smtp.central.cox.net
• Cox East: smtp.east.cox.net
• Cox Business: smarthost.coxmail.com
• Crosslink: smtp.crosslink.net
• DCANET: smtp-relay.dca.net
• Delmarva Online: mail-gw.dmv.com
• Delta Net: smtp.deltanet.com
• Direcway: smtp.direcway.com
• DSL Extreme: smtp.dslextreme.com
• Earthlink: mail.earthlink.net or smtp.earthlink.net
• Earthlink International: ismtp.earthlink.net
• Edge.net: mail.edge.net
• Enter: smtp.enter.net
• Erols: mail.erols.com
• Etisalat: smtp.emirates.net.ae
• Ezy: smtp.ezy.net
• Flash.Net: smtp.flash.yahoo.com
• Frontiernet.Net: smtp.frontiernet.net
• Frontline.Net: smtp.fcc.net
• Fuse.Net/Cincinnati Bell: smtp.fuse.net
• Gateway.Net: smtp.Gateway.net
• GTI: mail.gti.net
• GMail: smtp.gmail.com, Uses SSL on port 465 or 587
• HotMail: mail.hotmail.com
• IBM Global Net: smtp1.ibm.net
• ioNet Inc: mail.ionet.net
• Interaccess.com: smtp.interaccess.com
• Internet America: mail.airmail.net
• ITOL: mail.itol.com
• Juno: smtp.juno.com
• Mediacom: mail.mchsi.com
• Mediaone: smtp.ce.medione.net
• MegaPath: mail.megapathdsl.net
• MCI: mailrelay.mciworldcom.net mailrelay.internetmci.com
• Mindspring: smtp.mindspring.com
• MSN: smtp.email.msn.com
• MSN DSL: secure.smtp.email.msn.com
• Nauticom: mail.nauticom.net
• NEBI.com: mail.nebi.com
• Netcom: smtp.ix.netcom.com
• Netcom Canada: smtp.netcom.ca
• Netscape: smtp.isp.netscape.com
• NetZero: smtp.netzero.net
• Nvbell/Nevada Bell: smtp.nvbell.yahoo.com
• NYU.edu: smtp.nyu.edu
• OLG.com: mail.olg.com
• OOL/Optimum Online Internet Service: mail.optonline.net
• Pacbell/Pacific Bell: smtp.pacbell.yahoo.com
• Panix.com: mailhost.panix.com
• Patriot Media: smtp.patmedia.net
• PeoplePC: smtp.peoplepc.com
• Pipeline: smtp.pipeline.com
• Prodigy: smtp.prodigy.yahoo.com
• PSI.Net: relay.smtp.psi.net
• PTD.Net: mail.ptdprolog.net
• QIS: mail.qis.net
• Quixnet.net: smtp.quixnet.net
• Qwest Internet Service: pop.dnvr.qwest.net
• RCN: smtp.rcn.com
• Rider.edu: enigma.rider.edu
• RoadRunner: smtp-server..rr.com
• Rogers Hi-Speed: smtp.broadband.rogers.com
• SBC Global: smtp.sbcglobal.net
• SBC/Yahoo DSL: smtp.sbcglobal.yahoo.com
• Smallville Communications: mail.toto.net
• SNet: smtp.snet.yahoo.com
• SNiP: mail.snip.net
• Speakeasy: mail.speakeasy.net
• Spectrum DSL: mail.webstable.com
• SprintLink: smtp.a001.sprintmail.com
• Sprynet: m6.sprynet.com
• Starpower: smtp.starpower.net
• Swbell/Southwestern Bell: smtp.swbell.yahoo.com
• Sympatico: mailhost.sk.sympatico.ca
• The-Beach.net: mail.the-beach.net
• UMBC: smtp.gl.umbc.edu
• USA.NET: mail.netaddress.usa.net
• US Internet: smtp.usit.net
• UUNet: mail.uu.net
• Verio: smtp.veriomail.com
• Verizon: outgoing.verizon.net or smtpout.verizon.net
• Wans.net: smtp.wans.yahoo.com
• Wide Open West: smtp.mail.wideopenwest.com
• XO Communications: mail.njd.xo.com or smtp.concentric.net
• Yahoo: smtp.mail.yahoo.com
• Ziplink: smtp.ziplink.net