Ruby 1.9 brought major performance improvements to the table, and recently I got a chance to sit down and do some web service benchmarking. Based on my tests, the tradeoff between beauty and performance isn’t as big as it used to be, but there’s still some work to be done.

Here is what I did.

First, I implemented basic “Hello World” apps using the standard web server interfaces for each language; WSGI for Python and Rack for Ruby.

# Ruby: Simple Rack app
require 'rack'

class HelloWorld
  def call(env)
    [200, {"Content-Type" => "text/plain"}, ["Hello Rack!"]]
  end
end

# Python: Simple WSGI app
def simple_app(environ, start_response):
  start_response('200 OK[', [('Content-type','text/plain')])
  return ['Hello world!\n']

I also tested a simple Python app using Rawr, a fairly well-tuned WSGI/webob micro framework that I developed for Rackspace. Last–but not least–I also benchmarked a simple “Hello World” Sinatra app so I would have something to compare against Rawr.

# Ruby: Sinatra app showing tested route
require 'sinatra'

get '/hello' do
  'Hello world!'
end

# Python: Rawr app showing tested route
from rax.http import rawr

class HealthController(rawr.Controller):
  """Provides web service health info"""

def get(self):
  self.response.write("Alive and kicking!\n")

class TestApplication(rawr.Rawr):
  """Test class for encapsulating initialization"""

  def __init__(self):
    rawr.Rawr.__init__(self)

    # Setup routes
    self.add_route(r"/health$", HealthController),

app = TestApplication()

Ruby vs. Python: Web Performance

Everything was benchmarked by running multiple iterations of apache-bench from the terminal on my MBP. I used Green Unicorn as my test WSGI server, and Thin for Rack apps.

WSGI (PyPy 1.6.0): ~5300 req/sec
WSGI (Python 2.6.1): ~3200 req/sec
WSGI (Python 2.7.2): ~3000 req/sec

Rack (Ruby 1.9.2 MRI):  ~4500 req/sec
Rack (Ruby 1.8.7 MRI): ~4050 req/sec

Rawr/WSGI (PyPy 1.6.0): ~4900 req/sec
Rawr/WSGI (Python 2.6.1): ~2750 req/sec
Rawr/WSGI (Python 2.7.2): ~2700 req/sec

Sinatra/Rack (Ruby 1.9.2 MRI): ~1900 req/sec
Sinatra/Rack (Ruby 1.8.7 MRI): ~1399 req/sec

Ruby vs Python: Conclusions

Rack perf beats WSGI hands-down for standard Python (hooray!), although it is unclear how much of the difference is due to Green Unicorn vs. Thin. PyPy is astoundingly fast, but Ruby 1.9.2 isn’t too far behind.

Also, it was interesting to see what a difference Ruby 1.9 made when there was a lot of code to run through (Sinatra). This difference can also be seen in the Rawr tests with PyPy vs. standard Python.

The bad news is that Sinatra was significantly slower than Rawr (booh!). Given the benchmarks for a straight Rack app, I have to wonder whether a Ruby port of Rawr is in order.

Note: This article outlines a simple test of GETs returning small amounts of text. Before choosing a language for your next project, you will undoubtedly want to do more extensive testing, especially around concurrency, object serialization, request/response body size, and POST/PUT performance. You should also see how things look when you put everything behind a reverse proxy and/or load balancer, such as Nginx.

In the meantime, I just wanted to take a moment to summarize my current thoughts on the Ruby+POSIX vs. .NET+Microsoft stacks, having spent the last several years jumping back and forth between the two ecosystems.

Core dump:

• Visual Studio is extremely powerful. Their debugger is heads and shoulders above gdb, rdb, and pretty much any other *db on the planet.
• Static typing and compiled code is a nice security blanket when it comes to typos and refactoring. Yes, I’m addicted.
• Every Microsoft event I’ve been to in the last several years has felt stiff and enterprisey. The ecosystem is definitely headed more towards the world of IBM and Oracle, and farther away from the world of Apple and Google.
• The higher the suits/t-shirts ratio, the less fun and interesting things get. Microsoft isn’t fun anymore.
• On the other hand, the open-source/POSIX community is becoming more fun and interesting all the time. The community is vibrant, inventive, and supportive. They are more interested in the joy of the craft than in making a buck (although they do that too).
• The RoR community has grown up a lot in the past few years. We now have lots of lessons-learned and best practices to reference.
• CodePlex and NuGet are steps in the right direction, but aren’t really changing the wider Microsoft culture.
• MongoDB? Awesome. Linux? Awesome. Nginx? Awesome. Ruby 1.9? Awesome. Vim? Debatable.
• With the advent of Ruby 1.9, performance is now good enough. Character encoding woes are a thing of the past. The only thing I miss is my compiled-code security blanket. On the other hand, RSpec and Cucumber give me warm fuzzies.
• It’s a real shame that Python seems to be winning the mindshare war over Ruby. In my own experience and not-so-humble-opinion, Ruby is far more elegant, and package management is better. Python feels like a strange marriage of PHP and Ruby. The only thing that tempts me about Python is it’s speed (esp. PyPy), but recent releases of Ruby are fast enough for my needs.

Bottom line: The better performance and IDE are no longer as compelling an argument to stick with the .NET stack.

But wait! There’s hope! Nancy, Mono, Owin, etc. provide evidence that the .NET community is taking matters into their own hands. Stay tuned…

If you’re a game hacker (or know someone who is), check out my startup. We just launched the Indie Game Cloud Public Beta, and I’d love your help spreading the word.

Thanks in advance!

http://www.gammeta.com

</shamelessplug>

Can you abuse the singleton pattern? Certainly. Can you use it effectively? Absolutely.

A few questions I ask myself when deciding whether singletons really should be singletons:

1. Is the singleton external to my app? Databases, queuing services, and ESBs are all perfectly valid macro examples of the singleton pattern.
2. KISS: Is my entire app limited to 2-3 internal singletons?
3. DRY: Are my singletons inherently global? In other words, if they weren’t singletons, would I have to plumb references to them into almost every object? (e.g., a logger or mediator)?
4. Do my singletons depend only on each other, and/or the operating environment?
5. Have I ensured proper start-up and shut-down sequences for each singleton, including memory management considerations? For example, a “Grand Central”-style thread pool may require Run() and Shutdown() methods. These methods would be invoked during app startup and shutdown, so that tasks are guaranteed to run only when the objects they operate on are in a valid state.

What’s the difference between a mutex and a semaphore?

Ben:
 

The difference between a mutex and a semaphore? Well, a mutex allows only one thread at a time, while a semaphore can allow several threads to run at the same time.

Now, you’d like to probe a little deeper, so you follow up with:
 

OK. Can you give me an example of when you would use a semaphore instead of a mutex?

Ben thinks for a moment. This one’s a little harder to answer, but he remembers something he read once on the Internets:
 

Yeah, sure. You would use a semaphore when you need to control access to more than one resource. For example, if you’ve got a gas station with one restroom, you would only need one key, since only one person at a time can use the bathroom. You could use a mutex for that, which is basically just a binary semaphore.

Now, if your gas station had more than one restroom, you would need to use a semaphore so that more than one person could take care of business at the same time.

Not bad. But there’s a better answer.

The differences between a semaphore and a mutex are more subtle than most programmers realize. And, as we all know, Subtle Things have a way of turning themselves into Bad Things when nobody happens to be paying attention to them. Fortunately, you can (mostly) avoid the whole mess by following two simple rules of thumb:
 

Thow shalt use the mutex to protect all thy possessions that thou hast in common among you. This is the first and greatest commandment, and the second is like unto it. Thou shalt use the mutex and the condition variable to signal all thy workers in the field.

On these two commandments hang all the threads and the programs.

Semaphores have two traits that are particularly problematic. First, semaphores–as opposed to mutexes–have no notion of lock ownership. In other words, one thread can unlock a semaphore that was previously locked by a different thread. This is bad mojo.

In my house I have a very active 2-year old son. Now, as you may or may not know, 2-year olds are (a) too old to sleep in cribs (they just climb out), and (b) too young to stay put in a regular bed. This poses some unfortunate challenges at bed time. The solution? Turn out the lights and lock the bedroom door! Hooray! Eventually the kid will get bored and go to sleep! (This is what sleep-deprived parents everywhere desperately pray, as they lie silently in their beds.)

Unfortunately, 2-year olds have one more trait I didn’t mention: they are, without a doubt, too smart for their own good. This situation is compounded by the fact that the toddler in question happens to share his room with a big-brother (6 years old), who understandably finds it less-than-ideal to be locked in his own room, and who is also too smart for his own good.

It doesn’t take long for Big Brother to hack his way out of the room using a clip-on tie (hey, they’re stylish and practical!).

Semaphores, as it turns out, are surprisingly similar to locks on bedroom doors of ambitious children. It is really hard to ensure that once one thread (Dad) locks a semaphore, you don’t “accidentally” get another thread (Big Brother) unlocking it.

But wait! There’s more! Semaphores have yet one more issue, related to the first. It’s called Priority Inversion™. There’s actually a great little Windows CE article (yes, Windows CE of all things) over at MSDN that does a decent job explaining the problem:
 

Priority inversion occurs when a mutex, critical section, or semaphore resource held by a lower-priority thread delays the execution of a higher-priority thread when both are contending for the same resource.

For mutexes and critical sections, to correct this situation and free the higher-priority thread, with priority inheritance, Windows CE enables the lower-priority thread to inherit the more critical thread’s priority and run at the higher priority until it releases its use of the resource. This mechanism does not work for semaphores, which do not have a specific owner associated with them. Therefore, priority inversion may occur when using semaphores.

Because an unbounded amount of time is needed to relinquish the inverted thread and it is out of the control of the kernel, the OEM loses control of the scheduling process. To guarantee real-time performance, OEMs should ensure that a priority inversion condition does not occur.

Note that last line: “…[you] should ensure that a priority inversion condition does not occur.” Right. That sounds like a blast.

The bottom line is this: semaphores can be a royal pain. Fortunately, there are ways to avoid ever having to employ the little beasties:

1. For managing access to a shared resource where only ONE thread should be working with the resource at any one time, simply use a mutex. Note here that a mutex != a semaphore with a count of 1.
2. If you are implementing a classic producer/consumer model with a thread pool, strongly consider using a combination of a condition variable and mutex. Chances are that the threading library you are using supports this natively (e.g., pthread, Boost, Win32, .NET).
3. Do something wild and crazy, like switch to Erlang.

Bonus! You can choose from several specialized locks that can be more performant in certain situations, such as critical sections and multi-reader/single-writer locks. Any threading library worth its salt will support at least one or two specialized locks.

So, now that we’ve covered when not to use a semaphore, the question becomes: when should you use a semaphore? Honestly, I have no idea.

Monoliths “Unstrung”

One downside to the functional approach outlined in the article–that I didn’t see mentioned–is the fact that the interface is actually being split in a few cases, which is actually detrimental to cohesion. This happens when you have multiple overloaded forms of a function, and you keep one “flexible” one as a member function, but make the others external functions. Why not keep those as members for the sake of consistency? You can still implement them in terms of the one “flexible” member function, thereby continuing to ensure good encapsulation.

A few thoughts on applying the spirit of the law discussed in the article to other languages:

• C# – Use extension methods, but the “this” type should be as generic as possible. You still get the benefits of DRY but in a more object-oriented fashion that works well with Intellisense and cohesion. I like the extension  method approach better than the old static-methods approach (e.g., string.Join) because it still enforces good encapsulation, and is less verbose and more cohesive than the alternative.
• Ruby – Use mix-ins that use duct-type delegation to other methods. These can be automatically mixed into all applicable classes when the mix-in is “required”.
• Lisp – Brilliant! All you have are functions!

It’s also important to note the power you derive from combining this functional approach with lambda functions, function objects, and covariance.

See also: How Non-Member Functions Improve Encapsulation

Then, somehow, life came along and you had to be practical and, well, pay the rent. So now you make websites or program database access layers, or whatever.

But there is an indie revolution brewing. You’ve got tools such as Unity. Platforms like the iPhone. Indie-friendly publishing on major consoles for the first time ever.

Gammeta is the last piece of the puzzle. It’s the trump card that lets you compete with the big game shops.

Gammeta wants to make it easy for your indie game players to connect with friends and other players. We believe that bridging the gap between the virtual and real worlds is the future of gaming.

So, rather than spend a lot of time and money to develop and run a one-off backend server for your game, you can have Gammeta take care of it for you. Simple. Neat. Fast and easy. Magically delicious.

Are you an indie game developer? Let us know what you think.

[OperationContract]
[WebInvoke(UriTemplate = "/{encodedGameId}", Method = Verbs.Post)]
void AddSample(string gameId, Contracts.Sample newSample);
[WebDispatchFormatter]

If you leave off any of the query parameters for GetStatistics, WCF cheerfully returns “Method not allowed”. I wanted to make the “tag” parameter optional, and worried this would be a deal breaker.

Fortunately, I came across this WCF post by Ron Jacobs.

The basic idea is to leave off the optional query parameters in the UriTemplate, instead manually pulling them from the current request context. This approach is actually similar to the way you access query parameters in RoR, so I should have thought of doing it like this in the first place.

In fact, if you beef up Ron’s QueryString class, it can clean help you DRY up your code by taking care of data type conversions on the sly.

The moral of the story is that a framework’s design can induce sneaky biases that you only discover as they jump out of the shadows to bite you.

Thanks Ron!

One other significant reason that I like Windows is that I haven’t been running Windows XP for a long time. I was one of the brave few who decided to give Vista a try and I have to tell you, XP is absolutely archaic in comparison. Even more so when you compare XP to Windows 7. Windows 7 is very, very good.

A simple example of what you get when you upgrade from Windows XP is the ability to mute annoying system sounds, like those “online/offline” dings that I can’t seem to turn off in Trillian. I know this feature may seem trivial, but all these little goodies add up to a great experience.

Don’t get me wrong, I also like Mac OS X and Linux. If only PC manufacturers would raise their standards, more people would like Windows as well. Fortunately, looking at the announcements coming out of CES last week, things are trending in the right direction.

What do you think is a good domain name? Vote for one of the ones I’ve already come up with, or enter your own.

Note: I would LOVE to use cupcake.com but someone is squatting on that name.