It’s not Rails’s problem.
That argument debunked for most real world applications.
I liked the way different types of boundedness were presented:
- I/O-bound. Completing a unit of work earlier just means waiting longer for the next block/message.
- Memory-bound. Completing a unit of work earlier just means more time spent thrashing the virtual-memory system.
- Synchronization-bound (i.e. non-parallel). Completing a unit of work earlier just means waiting longer for another thread to release a lock or signal an event – and for the subsequent context switch.
- Algorithm-bound. There’s plenty of other work to do, and the program can get to it immediately, but it’s wasted work because a better algorithm would have avoided it altogether.
As much as I agree with the thrust of the article, C programs really are faster in real life, but I think it’s because people who program in C are more likely to be familiar with common performance problems and tradeoffs. It’s hard not to be at that level.
Great set of tips for eking out disk performance on MacOS X, like disabling last access time tracking. These are just as useful in non-SSD configs.
Looks like Aman and Joe knocked one out of the park with this presentation on Ruby’s GC:

I wish RailsLab or PeepCode or somebody would team up with those guys and do a series of screencasts. You can learn a ton just by watching over their shoulder while they work.
Chuck presents the results of a few ab runs against Thin and Unicorn. Surprising, even if the benchmarks lack rigor. I’d like to see good autobench runs for all of the backends on same hardware/network.
It’s a rough world out there, and we need to to a better job of thinking about and testing under realistic network conditions. A better mental model of bandwidth should include:
- packets-per-second
- packet latency
- upstream vs downstream
Densely informational piece. Don’t miss the part where they generate packet loss using a microwave and a cup of tea :)
Big giant list of articles, essays, tutorials, and tech talks on making the web faster. This is part of a larger Google Code project that asks, “what would be possible if browsing the web was as fast as turning the pages of a magazine?”
Another classic on latency vs. throughput. This one gets into the limitations of speed of light fairly quickly :)
Great talk from this year’s gogaruca conference. Anything that starts with a rail against the belief that tools can have mystical scaling powers is going to end up being a good talk :)
Great ideas for tweaking Ruby’s GC after applying Stefan’s Kaes’s GC patch. By the way, that patch has been an option on the ruby port in FreeBSD for years. It works. Apply it.
Aman Gupta and Joe Damato have implemented Fibers for the 1.8.6 and 1.8.7 MRIs. They’re patches now but will hopefully go into a 1.8.8 release. I had a chance to see these guys give a quick talk on their work at a local Ruby meetup — it was a hit.
“This module allows Ruby programs to access their OS’s native sendfile(2) system call from any IO object. Your kernel must export a recognized signature for the sendfile(2) system call to use this module. Currently, that includes Linux, Solaris and FreeBSD.”
Nice overview of caching from 1000 feet. Lays down some useful terminology, like “Cache Hit”, “Cache Miss”, “Storage Cost”, “Retrieval Cost”, “Invalidation”, “Replacement Policy”, etc.
David Heinemeier Hansson: “Rails Edge adopted Rack a while back and we’ve been exploring ways to expose that better. The first thing we did was to make it really easy to hook up any piece of Rack middleware in front of a Rails request. In your config/environment.rb file, you can do: config.middlewares.use(Rack::Cache, :verbose => true)”
Oh hell yes.
An Nginx module that acts as a gateway cache. I haven’t tried it yet but it’s a really good idea.
So I’ve been skeptical about Merb but I really like the world-view Ezra puts forth here: core framework code should be simple (no/little meta-programming), fast is good, Rack is awesome, etc.
“Varnish implementes a subset of the ESI Language 1.0 defined by W3C, this document lays out some of the thoughts and rationale for choices made and advice for usage of these features.”
This lets you perform includes at the cache layer so that each included resource can have its own caching policy. Akamai edge proxies have supported this for some time, apparently.
Dan Kegel: “You can buy a 1000MHz machine with 2 gigabytes of RAM and an 1000Mbit/sec Ethernet card for $1200 or so. Let’s see – at 20000 clients, that’s 50KHz, 100Kbytes, and 50Kbits/sec per client. It shouldn’t take any more horsepower than that to take four kilobytes from the disk and send them to the network once a second for each of twenty thousand clients. (That works out to $0.08 per client, by the way. Those $100/client licensing fees some operating systems charge are starting to look a little heavy!) So hardware is no longer the bottleneck. ”
Looks like this is from 2003 but is still pretty accurate as far as I can tell.
Right on time.
Yossi Kreinin: “But I miss virtual functions. I really do. I sincerely think that each and every notable feature C++ adds to C makes the language worse, with the single exception of virtual functions.”
I’m more than a little embarased that I’ve never heard of this utility. I think most modern kernels prioritize IO with normal nice, though…
Evan Weaver: “These leaks tend to grow slowly. Your Rails app definitely has this kind of leak, especially if it uses the ActiveRecord session store.”