Matt, M.S.

Since you're not cool if you don't have a vector version of yourself on your techincal blog these days, I've decided to create one of myself... after a few beers and using only my trackpad. They call Picaso a genius right?

A couple weeks ago I ran a few benchmarks on Passenger vs. Mongrel. I found that Passenger was much slower than Nginx and Mongrel. Today I read that the Rails Wiki is now running on Passenger; my curiousity piqued, I checked out the site.

Much to my surprise, the site was amazingly responsive.

Alright. Did I do something wrong? Perhaps I missed something? I created a fresh Amazon EC2 instance (m1.large if interested), and recreated my earlier Passenger setup. One thing that I did notice that I may have done differently this time was that I might not have installed my gems with the freshly installed Ruby Enterprise Edition (REE).

(Which looks something like this:)

/opt/ruby-enterprise-1.8.6-20080709/bin/ruby /opt/ruby-enterprise-1.8.6-20080709/bin/gem install aws-s3

One other thing might be that I commented out the 'PassengerRuby' line when I updated Apache's config to use REE.

#PassengerRuby /usr/bin/ruby
RailsRuby /opt/ruby-enterprise-1.8.6-20080709/bin/ruby

Either way, I reran the benchmarks and was really quite surprised:

So what does this all mean? Who wins?

Good question.

It seems that both of the benchmarks are slower than those previously run! My conclusion is that results all over the place as network conditions obviously affect response time. For the sake of clarity, I've used a 15Mb/2Mb connection for all benchmarks.

This time around REE seems much more responsive than it did before all the while using 1.35 less load than its Nginx/Mongrel counterpart. The Nginx instance seems about as responsive as it normally feels, but the difference in load is quite an eye opener. This information coupled with Passenger's ease of use make it quite the contender.

I think I'll try Passenger for a while on my production server. It's easier to maintain and hell, maybe even faster. I'll report back with further findings.

Thanks to the Wayback Machine, I was able to find an blog post I posted almost exactly two years ago bitching about users. This article made the front page of Digg (1338 diggs) and nearly melted my home Apache server in the process. I'm reposting it here for posterity's sake.

Here is the original text:

July 25th, 2006 @ 5:40:18pm EDT | Category: General | 22,672 Views

My rebuttal to the NetworkWorld article "What Users Hate About IT Pros":

Users are an interesting bunch. While most are very nice and understand that everything in the world isn’t perfect, many demand miracles. Why six somewhat universal IT gripes? Why not?

1. Users Lie - Many times I chalk up user misinformation to a lack of technical knowledge, but Users will also tell you straight-out lies. Perhaps they feel guilty about breaking something, but lying about the symptoms of the problem at hand only further prevent the solution.

2. Management Doesn’t Understand - Bosses understand what the IT Department does, sort of. Yet they control the budgets, personnel, and usually make IT related decisions without input. We are then expected to make it work right off the bat no matter what else might need our attention. Part of the trouble with being an IT Pro is that we are like a movie editor; you only notice us when we fuck up.

3. Perfection Expectation - IT Pros are expected to know how to fix every model of every device ever manufactured. If it has a screen or plugs into a socket, we are expected not only to know how to use it, but also to troubleshoot and fix it. Immediately. Without a manual. Hey, a copy machine is like a computer right?

4. Every User’s Problem is Our #1 Priority - Many Users will run into the IT Department screaming that their "Internet" is broken and it must be fixed immediately. While we understand the pictures of your Mom’s new dog are insanely important, we might be busy doing something that might rank over your issue, like ensuring that the entire company is receiving email, or fighting off an attack from some Korean kid. IT Pros across the world could work eight days a week and never solve every issue.

5. Some Things Just Won’t Work - We program computers with logical instructions, but as everyone knows, they do not behave logically. Not every device can work with every other device. Standards are not standard, as there are different implementations of every standard ever made. I would love to sync your iPod to your cell phone via a bluetooth connection; it should work right? When we say that it cannot work, take our word for it. We are the professionals after all.

6. Personal Pro - We don’t mind answering a question a User might have about their home computer setup, but they must keep in mind that everyone in the company does the same thing. We try to be kind and helpful, but sometimes we are really busy and tired of the grind. If a local IT Pro starts you off on the right path, GOOGLE for the next steps. We do not have the time to hold everyone’s hand fixing their Mother’s 1986 Packard Bell setup. We understand the concept of "Teach a man to fish…", but Users need to understand that exterior systems are their responsibility.

To be fair, I’m sure that these issues can be applied to any field of work. Hey, we’re all overworked and underpaid, right?

RESTful_ACL has been updated for the first time in nearly three months!

Global Admin Access

Due to popular demand (well, alright, I needed it on a project), site administrators get full global access to all RESTful_ACL resources. The trick? Make sure that your User model defines an "is_admin?" method or "is_admin" attribute. Before RESTful_ACL does a thing it will now check for this method/attribute to see if the @current_user is an Admin. If so, viola!, you're in. It's like that scene in Goodfellas where Henry and Karen get into the nightclub via the kitchen. Bobby Vinton and all.

New View Helpers

I've added four new view helpers that are less verbose than the old style:

Old Style:

if Job.is_creatable_by(@current_user)
  ...
end

Super New And Improved Deluxe Style:

if creatable
  ...
end

The new style automatically assumes that you're talking about the @current_user's permissions on the current resource, so you don't have to specify it over and over and over and over. These new helpers also take "is_admin?" into account as noted above.

The old style will still work so no update worries.

Grab it now on Github!

I happened to be in a hospital room when I noticed a machine in the corner that was showing a screensaver full of helpful messages. This was one of them:

There is a bunch of hubbub around the Rails community about Passenger (mod_rails). It really simplifies Rails application deployment, but how does it stack up against the venerable Nginx and Mongrel scheme?

My curiosity piqued, I decided to benchmark my current application. All three benchmarks were conducted on Amazon Web Services' cloud using an Fedora 8 x64 instance with 8G of RAM.

Each instance was tested using Apache's 'ab' tool with 10 concurrent requests over 1000 connections. Each request used authentication and ssl.

As you can see, Nginx with five Mongrel instances is faster than Passenger, and honestly, you can feel some sluggishness using Passenger.

Passenger Pros:
1. Ridiculously easy to install.
2. You don't have to restart Mongrel processes when you deploy changes to your application.
3. It's still early in the game, so it can only get faster.
4. Every shared host in the world supports Apache.

Passenger Cons:
1. Noticably sluggish request cycles compared to Nginx/Mongrel
2. Ruby Enterprise Edition doesn't really seem to do anything
3. Seems to be more of a resource hog than their writeup suggests -- I also tested Passenger on an i386 instance with 2G RAM and the damned box nearly melted. Seriously.

Nginx/Mongrel Pros:
1. Faster
2. Nginx is easier to configure than Apache
3. Widely heralded as the current best practice deployment scheme for production environments

Nginx/Mongrel Cons:
1. Comparatively painful to deploy
2. Deploying changes to your application can be trickier
... So my conclusion?

Nginx/Mongrel wins this round. Deployment is much more complex, but also noticably more responsive. Ease of installation is nice, but you only deploy your application from scratch once!