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.

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

[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!

Lots of these words are obscure, and therefore useless. For example, what’s an abaca?

Perfect for making your own T-Shirt. Like, you could put 7e55e118 below a mesh , and only CG hackers would understand.

No other operating system can match Windows for the number of devices supported, but it definitely comes with a trade-off. If you have fallen prey to a poorly-written driver, don’t despair! All you need to do is whip out your trusty copy of WinDbg, and within a few minutes that wimpy driver will cower before your superior kernel ninja skills!

Learn how to debug Windows BSOD crashes. Also, here is a more general tutorial on WinDbg.

Now, once you’ve found the culprit, you have three options. Choose wisely:

1. Get the latest driver from Windows Update or the device manufacturer’s website.
2. Replace the rogue device with something from a company who actually tests their hardware before shipping it.
3. Buy a Mac. They never crash, right?

XFS does not support dirent::d_type

What the?! In other words, a line such as this will always be false:

de->d_type == DT_FIFO

Jungle Disk uses readdir_r() to list files and check their types. Uh oh. That means that on XFS partitions, everything looks like a regular file! You can see this for yourself using code like this:

#include <iostream>
#include <cstdlib>
#include <dirent.h>
#include <sys/stat.h>

using namespace std;

int main(int argc, char *argv[])
{

  dirent holdde;
  dirent *de;
  struct stat st;

  cout << "DT_BLK = " << DT_BLK << endl;
  cout << "DT_CHR = " << DT_CHR << endl;
  cout << "DT_DIR = " << DT_DIR << endl;
  cout << "DT_FIFO = " << DT_FIFO << endl;
  cout << "DT_LNK = " << DT_LNK << endl;
  cout << "DT_REG = " << DT_REG << endl;
  cout << "DT_SOCK = " << DT_SOCK << endl;
  cout << "DT_UNKNOWN = " << DT_LNK << endl;

  DIR *dir = opendir("/home/vmuser/xfs");
  while (readdir_r(dir, &holdde, &de) == 0 && de)
  {
	  cout << de->d_name << " [" << (int)de->d_type << "] " << endl;
  }
  closedir(dir);

  lstat("/home/vmuser/xfs/TESTFIFO", &st);
  if (S_ISFIFO(st.st_mode))
	  cout << "XFS FIFO detected: " << st.st_mode << endl; 

  lstat("/home/vmuser/ext3/TESTFIFO", &st);
  if ((st.st_mode & S_IFIFO) != 0)
	  cout << "EXT3 FIFO detected: " << st.st_mode << endl; 

  return EXIT_SUCCESS;
}

So what’s the solution? Good old, reliable stat(). That function does work with XFS on Linux. Unfortunately, this means you will have to make an extra call for each file after listing the dir.

If you are interesting in hacking the Wii, you need to check out WiiBrew. This is the place to go for information about compiling, running, and debugging your own custom Wii apps. For example, WiiBrew is where I found out about the excellent Homebrew Channel.

Dotbatman is porting the cult classic Super Mario War to the Wii. What are you going to do?

Update: You no longer need a copy of Zelda to install the Homebrew Channel! Check out the latest Bannerbomb hack.