CoverItLive tries to reassure users after VP debate server overload

Tomorrow night, of course, is the second presidential debate, and I'll be live-blogging it here, starting at 8:00 PM EDT. (The actual debate starts at 9:00.) I was originally thinking of driving to Nashville and trying to go to some pre- and post-debate rallies, but it sounds like neither candidate is actually planning to make an appearance (and why would they? Tennessee is about as safe of a "safe state" as there is, outside of Utah). And anyway we're heading to Denver on Wednesday night, to look for a place to live, flying out of Nashville, no less. So making Tuesday a crazy, wee-hours, driving-across-the-state sort of night might not be the best idea. Accordingly, I'll be live-blogging from my couch, with Becky -- and possibly Dmytro, who is coming to visit us -- at my side. There may even be a webcam this time, at least for part of the debate. :)

My liveblog software of choice will, again, be CoverItLive. This is something of a leap of faith, as they experienced a server crash during the vice presidential debate last Thursday, then put a throttle on new viewers, which was very annoying. I obviously wasn't the only person annoyed, as this morning they sent out a mass e-mail to their users, trying to reassure us that they're ready to handle high-traffic events going forward:

Hello,

My name is Keith McSpurren. I am the President of CoveritLive.

We have put the necessary upgrades in place to ensure that 100% of your readers will be able to enjoy/participate in your live blogs of the upcoming Presidential debate on Tuesday and beyond.

As some of you may have noticed, as a precaution during last weeks’ Vice Presidential debate, we held back any new readers at different times so that we could ensure the tens of thousands of readers and the writers using CoveritLive could stay online without interruption. Although blunt, it appeared to do the job. Based on our information, the systemwide readership could have been higher by another 30% had we not had this limitation. Of course, that number would vary depending on when your event started and when your readers wanted to join. We hope the times we need to use this technique are few and far between.

To be clear, this was a system wide capacity notification. No one, even our largest users, has ever approached reader limitations during one of their events. The issue was primarily due to: a) the incredible interest in the debate; and, b) the thousands of new users who have begun using CoveritLive in the past three months.

We always try to keep our available capacity at 3X our previous largest day which up until that date had served us well. We will continue to do our best to stay well ahead of our usage but will keep this safeguard ready to ensure that if this type of anomaly happens again, the impact will be marginal.

In my private e-mail correspondence with CIL last week, I was told the traffic for the VP debate was five times the traffic for the first presidential debate. They weren't expecting quite that big of a surge, which is why they were caught off guard.

One thing their e-mail fails to acknowledge is that, prior to the institution of the "blunt" limits on new readers last Thursday, there was a server overload -- between roughly 9:00 and 9:09 PM EDT, by my reckoning -- which prevented "the tens of thousands of readers and the writers using CoveritLive [from staying] online without interruption." Perhaps this overload only affected some folks, but I know in my case, I was unable to blog during that time, as my liveblog console was replaced by a CoverItLive server error message. Several readers told me an error appeared on their screens as well. This was actually the second time I'd seen such an error -- it also happened just after the first presidential debate, preventing me from logging out of that liveblog until morning.

I am, for the moment, trusting CIL that these issues will not be repeated in future debates, nor (most importantly) on election night. (If nothing else, last week's problems will probably scare some users away, reducing the strain.) But I'm also readying a backup plan: in the event CoverItLive crashes again, I'll have an alternative liveblogging page, perhaps a WordPress post or perhaps a live-Twittering widget (I haven't decided yet), ready to take its place on my blog at a moment's notice.

What I'm not planning to do is switch my whole liveblog into the Chatroll "live chat" window, as several readers suggested last week. I actually received an e-mail from Chatroll after Thursday's debate, picking up on those suggestions and asking "what features or changes [I] might suggest which would enable [me] to use Chatroll more effectively for live blogging." I happily wrote back with a long list of suggestions, which are reproduced, in part, below:

First and foremost, the "holy grail" would be the ability to automatically, in real time, separate out MY comments into an separate window (which would not allow for reader response), while ALSO having them appear in the full chat window (which would). Thus, for instance, I could have a version of the embedded chat on my homepage, showing only MY liveblogging, with a "click here to read and make comments" link, which would then go to the full version of the same chat, which would contain my liveblogging AND other people's chatting. This is, in my mind, crucial to the concept of "liveblogging": if I'm liveblogging an event, that means I'm describing it chronologically, from my perspective, not merely as a single participant in a large chat room, wherein my comments quickly scroll away and get lost in the noise. The chat room is a bonus feature for people who want to get more deeply involved, but the core premise of the "liveblog" is that *I* am blogging it, and people can read what I'm writing. ... This is the #1 reason why I currently use CoverItLive for liveblogging, because it allows me to turn off reader comments and just *blog*. But then I couple it with Chatroll, so readers can "talk back" in real time, too. It's a bit of an awkward arrangement, but it at least attempts to serve the two purposes simultaneously: allowing me to truly liveblog, while allowing readers to talk back. But it would be even better if I could combine the two functions in an automated fashion, so that if I type something, it would effectively appear in BOTH the liveblog AND the livechat. And then I could let each individual reader choose which window they prefer.

Another important feature would be the ability to have more than the 10 most recent comments appear in the chat wiidow. With CoverItLive, you can scroll all the way back up to the top of the liveblog. With Chatroll, you have to go to the "archive" page to do that, and then go through page-by-page. That's way too cumbersome to allow someone to "catch up" on portions of a liveblog, or live chat, that they've missed.

Also, live polls would be great. CoverItLive handles that feature very, very well, and it's one reason I'd be loathe to give CIL up. ...

I'd [also] like to see...the ability to EDIT my comments (another crucially important CoverItLive feature, which I've used repeatedly to correct typos, fix HTML, etc.), and the ability to ban abusive users by nickname or IP address (this has not been a problem yet, but I imagine it could potentially become one). ...

[I'd also like] the ability to turn off a chat room when I'm done with it. Correct me if I'm wrong, but I don't think this is possible now -- and my last chat (from the presidential debate) has been receiving some after-the-fact traffic that essentially amounts to political spam. It's not hard to imagine commercial spam filling that niche eventually. I should be able to shut the chat off when I'm done with it. Ideally, the embed window would then either have a "replay" gloss, like CoverItLive's does, or else it would default back to the top of the chat, with the user having the ability to scroll all the way from the beginning to the end.

Also, another somewhat big deal: it would be great if I could export the contents of the chat somehow. Into an HTML file, a text file, an excel file, whatever. But some sort of explicit export feature, so that I would feel comfortable that, even if Chatroll disappears at some point (no offense!), I won't lose my data.

I seriously doubt those suggestions -- particularly the first one, which arguably runs counter to the whole concept of what Chatroll fundamentally is, as a live-chat service -- will all be implemented before election day. So I will most likely stick with CoverItLive. But it's great to see both services making active strides to improve what they offer users.