Hmm, this is a bit higher than expected…
Picked up from Nothing Up My Sleeve.
What do you get when you cross an XRG release with Murphy’s law? I can understand yesterday’s bandwidth fiasco, which was mostly my fault for not planning better, but this is getting rediculous.
Wednesday, 1:30pm: The power goes out. First thought: Ohh, shit. Second thought: No problem, got the servers on a UPS, everything should be fine. Went downstairs to check, things were okay, brought an extension cord over to power the wireless modem on the UPS as well, link went back up fine.
Wednesday, 2:00pm: UPS power runs dry. Thinking first thought a lot more now.
So now I’m writing this blog entry on my Powerbook, hoping the power will come back on soon. The only saving grace is the XRG mirror download that I posted yesterday is listed as “Download 2” on MacUpdate. Of course, if anyone is linking in from anywhere else, they won’t be getting anything.
So the lesson of today is… if releasing a software application, make sure you have your entire site hosted with a good hosting provider. Ohh, and the MacMini is still cool. 🙂
Update: Power came back on slightly after 3:00pm.
XRG 1.1 was released this morning. I thought I’d try out releasing the same day as the MacWorld keynote just to see how it goes. So far, it’s been going really well or horrible, depending on how you look at it.
The good part is that about 1200 copies of XRG have been downloaded during the past 6 hours. The bad part is that I severely under-estimated the amount of bandwidth required when doing a software release (hmm, 1200 * 1.2Mb/copy = 1.44Gb + normal web traffic). Since the beginning, I’ve hosted the XRG web site on my own machine, and offered the XRG downloads from a machine at Ephibian. This was never a problem, and my web server (at the time on a 40K/sec uplink) always had plenty of bandwidth to spare, so I thought that hosting both the site and the downloads in-house on a 90K/sec uplink would work out well. Oh was I ever wrong. Within an hour of releasing, my connection was completely saturated and the server was handling over 90 connections concurrently. The network connection remained pegged for about 4 hours after that, and has only now started to trickle down a bit.
At first, I couldn’t think of any way to handle it and thought I was pretty much screwed, then I thought of a few things that helped out a bit. The first thing I did was set up a download mirror back on the old web server with a 40K/sec uplink. This helped less than I thought it would because, unfortunately, not too many people choose to download from a mirror site. The second thing I did was turn off my web log analyzer, not because it was taking too much CPU (actually, the server never broke a sweat really), but because I have the analyzer configured to do DNS lookups on the IPs that hit the server so I can see a pretty graph on where people are coming from throughout the world. 🙂 Usually, the analyzer runs every 2 hours, but I figured it could wait for awhile. This ended up helping more than I thought it would; I guess the number of DNS connections made would have been pretty high. This probably benefited the web page traffic the most, since a reduced number of connections on the network would improve the speed of short-term network connections dramatically.
So the lesson of the day is: If you release a software application, make sure you store the download(s) with a good hosting provider. I suppose the benefit of today’s events is that I’ll know this when releasing an application that I’ll actually be charging for. 🙂 I’ll probably post a followup blog entry on the release in a few days.
PS: MacMini? Sweeeeet… If I would have had this choice a few months ago my computer purchase would have been a lot more difficult. A compile farm of about 5-6 of these things would probably work faster than my 2.5Ghz G5 could chug through compiling apps. And then there would have been the numerous possibilites… 2Ghz G5 + MiniMac, or 1.8Ghz G5 with 2 MiniMacs, etc. Maybe it’s better I did buy my computer before these came out. 🙂
It’s been quite awhile since I’ve posted anything here, and that’s mostly a result of a busy holiday season, but Gaucho Software has been keeping me busier than usual as well.
After the release of Dash Monitors 1.0, I’ve received a lot of interest from 3rd parties about it’s continued development. Since the second dashboard contest deadline was on January 5th, I decided to set aside everything else and really go all out on Dash Monitors development. When January 4th came around, I ended up with a product that is far better than it was at version 1.0. A screenshot the graphical view of the widget appears on the right (I know, the image quality sucks…software bug…). Just to give a bit of an explanation of the Disk monitor…as you transfer to/from the hard disk faster, the discs will spin faster. The other graphs work pretty much as you see them. So we’ll see if it wins the contest or not…either way I believe Dash Monitors will be a great Widget to sell once I polish it up some more and Tiger ships.
Speaking of Tiger, the development builds are getting much more stable as time goes on, and I expect that Steve Jobs will announce an expected release date for Tiger at his MacWorld Expo keynote. Reminds me of a bar conversation back at WWDC where a few of us gave our initial predictions for a Tiger release date. Now I’m thinking May 15th might be a bit too late, but I’ll still stick with it.
As some of you may know, I was getting ready to release another version of XRG when the Dash Monitors development really kicked up again. This week, now that I can take a bit of a breather, I’m back to finishing up XRG 1.1. It’s looking pretty good so far and I expect to release it as soon as I can test the temperature graph on the iMac G5 to make sure all the sensors are showing up correctly. I haven’t decided if I want to push for next week so I have a MacWorld Expo release, or if I want to wait until the week after when it will be less likely to be overlooked in all the other MacWorld software releases.