A big life change like leaving your startup is sometimes long overdue. If you’re fortunate enough to have saved some money and still have airline status from all those business trips you took then buy a vacation to Mexico and have some free beers in the club. Enjoy it while you can because your status will run out and you might be too busy soon on your next startup idea.
Disney officials have just released the rules for an exciting new contest. Wear as much blue as possible, hoodies encouraged, and you and your family could win an all expense paid trip to Disney World. Judges will be lurking near the corner of 24th and Treat at approximately 11pm every night this week. More details to follow.
I am eating cheese ravioli.
I signed up for twitter for a while ago. I tried to get all my friends to join so they could find out what kind of raviloli I was eating now but they all refused to join. What are they doing that’s better than knowing about about my dinner? I searched for awhile to find the epitomy of twits.
I saw this guy at Kirkwood a few weeks ago. There’s a camera on his helmet.
I will no longer be using this blog for technical posts. Check out the new Spongecell Tech Blog for all future technical postings by the engineering team.
Maybe I’ll keep using this blog for funny pictures of the CEO.
I did some performance testing of different server technologies on one of our AMD Sempron 2600s since we are thinking about upgrading our servers. Spongecell uses Ruby on Rails 1.1.6 and MySql 5.0.24a.
Here’s the lineup:
I pounded each of these servers with Apache Bench hitting one of our event/view links .e.g. ArnoCorp. This is a rails action that does some sql queries and renders rhtml.
/usr/sbin/ab -c100 -n500 http://127.0.0.1/event/view/id
All three servers performed similarly. FastCGI maxed at 19.1 requests/second whereas Mongrel only got to 17.1 requests/second. The optimum number of processes seemed to be about 12 for each server type. For serving a small static html file the Apache servers served ~1700 per second and Pound served 450.
Mongrel and Pound are very easy to set up. In terms of performance, FastCGI is ahead by about 10%. I’m not sure 10% is significant enough to justify using FastCGI, it might be. We had FastCGI configured poorly for awhile and it led to some instabilities. FastCGI is a little tricky to configure for the first time unless you’re very familiar with httpd.conf. Since Spongecell has experience with FastCGI I suspect we will stick with it. For someone setting up a Rails server for the first time I would recommend using Pound to start with. You can then switch to Apache when you need more features or when serving static content becomes important.
Rail’s Analyzer with Klass
Download it: rawk.rb
run ruby rawk.rb -h for help.
I wanted to analyze Spongecell’s log file to see where the most of our cpu time was being used. I checked out rails-analyzer.rubyforge.org and after navigating myself in circles following the links I finally decided to download some stuff, install some gems, and give it a try. It didn’t work.
I didn’t understand why I needed whole packages just to look at one log file. I could get a lot of information from the logs just using grep. So I started to write a tool in awk until Tom told me I should use ruby.
Of course I should use ruby.
Rawk is the result. Many sets of data are presented and grouped in many ways. The first thing you will want to optimize are probably the actions that your server sepnds the most time on. I ran rawk on our log a few minutes ago:
The four most expensive requests for Spongecell are the poller (for keeping your calendar display up to date), iCalendar feeds from Spongecell, the normal web view of Spongecell, and RSS feeds.
Please give this tool a try and let me know what you think. I’m happy to include improvements or make modifications.
** This script is released as beerware, something I first heard about on a mac bittorrent client. They defined it as software that is free and if you like it you should buy yourself a beer.
I went to the Future of Web Apps in London earlier this year as Spongecell’s avid blog readers already know. In SF all I do is crash the parties. Last night the party was at Mighty in Potrero Hill.
This is James Hamilton of Yahoo! He is a prominent PM in the media division and did some very successful networking in between shots of Patron. In this picture I caught him illuminated by the Google schwag light cubes. What would be better than a heat generating plastic light in your premium cocktail? Answer: ice.
I saw Cal Henderson of Flickr in London and here he is again in SF. He was trying to see how much Google schwag he could fit in his mouth. According to my watch he just finished his talk at the conference.
I went to the Scale with Rails conference last week in Laguna Beach. I didn’t take any pictures of the six of us sitting there with our matching silver macbooks but here’s a picture of Dylan at Hennesy’s on karaoke night.
The conference was really more of a fireside chat. Jason told us about his experiences and was able to give us some rules of thumb about scaling and configurations. This will probably save me some time in the future when I am experimenting with different setups for Spongecell.
I was very interested to learn about DB scaling. Some sites that have proved their ability to grow often have data that is easily partitioned by user. For example, email sites can easily partition data. Google calendar has limited sharing of events. You typically have to copy an event if you want it on your calendar. Spongecell wants better social information so we want people to be sharing events as much as possible. Can we scale and still do this?
On day 2 we did some benchmarking. We also saw dtrace in action. This tool profiles the entire system but currently is only on solaris. Supposedly it’ll be in Jaguar.
I stayed a few days after the conference to enjoy the south coast and work on tanning my receding hair line.
We walked across the border coming back from TJ and even though they x-rayed my bag we still got some fireworks and cuban cigars home.