Compound Thinking

Threads, Processes, Rails, TurboGears, and Scalability

Threads may not be be best way, or the only way, to scale out your code. Multi-process solutions seem more and more attractive to me.

Unfortunately multi-process and the JVM are currently two tastes that don’t taste great together. You can do it, but it’s not the kind of thing you want to do too much. So, the Jruby guys had a problem — Rail’s scalability story is only multi-process (rails core is NOT thread safe), and Java’s not so good that that….

Solution: Running “multiple isolated execution environments” in a single java process.

I think that’s a neat hack. The JRuby team is to be congratulated in making this work. It lets Rails mix multi-process concurrency with multi-threaded concurrency, if only on the JVM. But it’s likely to incur some memory bloat, so it’s probably not as good as it would be if Rails itself were to become threadsafe.

I’m not sure that the Jython folks have done anything like this. And I’m not sure they should. It’s a solution python folks don’t really have. Django used to have some thread-safety issues, but those have been worked out on some level. While the Django people aren’t promising anything about thread safety, it seems that there are enough people using it in a multi-threaded environment to notice if anything’s not working right.

At the same time, TurboGears has been threadsafe, from the beginning, as has Pylons, Zope, and many other python web dev tools. The point is, you have good web-framework options, without resorting to multiple python environments in one JVM.

Why you actually want multi-threaded execution…

In TurboGears we’ve found that the combination of both multi-threaded and multi-process concurrency works significantly better than either one would alone. This allows us to use threads to maximize the throughput of one process up to the point where python’s interpreter lock becomes the bottleneck, and use multi-processing to scale beyond that point, and to provide additional system redundancy.

A multi threaded system is particularly important for people who use Windows, which makes multi-process computing much more memory intensive than it needs to be. As my Grandma always said Windows “can’t fork worth a damn.” ;)

But, given how hard multi-threaded computing can be to get right TurboGears and related projects work hard to keep our threads isolated and not manipulate any shared resources across threads. So, really it’s kinda like shared-memory optimized micro-processes running inside larger OS level processes, and that makes multi-threaded applications a lot more reasonable to wrap your brain around. Once you start down the path of lock managment the non-deterministic character of the system can quickly overwhelm your brain.

As far as i can see, the same would be true for a Ruby web server in Ruby 1.9, where there is both OS level thread support and an interpreter lock.

I’m well aware of the fact that stackless, twisted, and Nginx have proved that there are other (asynchronous) methods that can easily outperform the multi-threaded+multi-process model throughput/concurrency per unit of server hardware. The async model requires thinking about the problem space pretty differently, so it’s not a drop in replacement, but for some problems async is definitely the way to go.

Anyway, hats off to the Jruby team, and here’s hoping that Rails itself becomes threadsafe at some point in the future.

So many revolutions, so little time.

Tim Bray is blogging about “inflection points” in the uptake of various technologies.

Python get’s a very positive review:

Today you’d be nuts not to look seriously at PHP, Python, and Ruby.

So, the rise of the so-called scripting languages is one of the inflection points, but it’s not the only one.

He singles out web-framework development as one place where there’s a lot of stuff happening, and a lot of new “rails-like” frameworks are cropping up all the time. TurboGears will live or die in the context of a much larger web-development revolution, and we need to be prepared to make our way forward in the midst of that.

What comes after rails will not be a rails clone. It will learn the right lessons from rails, avoid the pitfalls of rails, but it will also need to carve out something new and better than rails. For RDBMS users, I think the key difference between TG and Rails is the power and flexibility of SQLAlchemy. We need to “sell” this better.

There are a lot of other revolutions coming according to Tim. And I do think we’re looking at big changes in terms of everything from programming language choice, to web-development tools, to end-user desktops, and data persistence mechanisms. We’re also just beginning to see what the world of high-end javascript and other “rich” internet applications is going to do to our view of end-user software.

He doesn’t even mention the rise of EC2 and the Google App Engine as sea-changes in the way we buy computational resources, and I think that’s going to have a huge impact.

In the end my prediction is that the way we develop applications will change more in the next 5 years than it did in the last 5, and it’s time to start getting our heads wrapped around these issues, or we’ll be left behind.

TurboGears 2 sprint

I’ll be hosting a TG2 sprint here in Ann Arbor Michigan on October 27th, hopefully we’ll also have a large virtual presence from folks around the world.

I’ve created a page on the Wiki for Sprint Organization tasks: http://docs.turbogears.org/SprintOrganization

If the sprint goes well it could get us very, very close to the point where we could reasonably do a TurboGears 2 technology preview release.

The main things we’ll need to do is sync up with the latest pylons, improve our tests, and do some basic doc organization work (migrate some information from the doc strings to the docs wiki, and create some pages which link to external docs). There’s lots of other things I want to do like improve out user authentication/authorization/registration support, or create a toolbox tool for helping create SQLAlchemy models. So, there’s tasks for anybody who can lend a hand.

If you’re available and want to help out (either attending physically or virtually), feel free to add your name to the wiki.

Likewise, if you can host a in-person sprint in another location, please feel free to edit the wiki with that information.

Relational Databases as an “implementaiton detail?”

I found this little tidbit in amidst the hugely overraught comment treads on Derik’s post describing his return to PHP from the wonderful world of Ruby on Rails:

I loved the part about the database as an “implementation detail.” That sings to me.

–Daniel Waite

And, in spite of the poetic hyperbole of folks like Daniel, I think relational databases exist for good reasons and knowing about how they work is a good thing. Active record treats the database kinda like a big hash table in the sky, which is OK for some applications, but not so OK for others.

I find that large, complex apps have a way of growing in unexpected ways over time — and relational algebra is much better designed to handle unexpected requests for complex datasets than hash tables or even the most well designed objects. SQL, and relational algebra are implementation details in the same way that using a hammer is an implementation detail in building a tree house. Sure you can do without, but you will have a harder time, and will definitely end up building a different treehouse!

Don’t misunderstand me, Object’s are good things, and I sure as hell hope people understand them, use them, and make great software with them. But relational algebra is a good thing too. And it’s become clear that any really good database toolkit can’t forsake one in favor of the other, and that’s why SQLAlchemy, Storm, DejaVu, and Hibernate are all better tools than Rails’ Active Record.

As for Derik’s original article. In spite of all the brouhaha, Derek’s post basically says: “hey I liked Rails, and I learned a lot about good programming from it. And ultimately it was easier to get my site rewrite done in PHP because I learned rails first.”

I think it’s obvious that Rails could have done the job for Derek, but two things got in the way:

• everything was already in PHP so Rails wasn’t and incremental update, it was a rewrite.
• Active Record got in the way of using SQL as a relational algebra engine, rather than a glorified hash persistence mechanism.

TurboGears users should pay attention to both points. If you have a large complex app, you’ll be better off with an ORM that treats SQL as a full partner, which is why we’re migrating the defaults to SQLALchemy which does a fantastic job of making both relatinal algebra, and object oriented programming part of it’s core.

The second point is much harder to deal with, but if you can wrap existing application functionality in a larger TurboGears app, and migrate it piece by piece you’ll definitely have more success. I’ve been doing a lot of Web Service architecture stuff this year, and that’s proven to be a great way to connect existing resources to TurboGears applications.

Change the World — One Program at a Time

This is a very late comment about Pycon2007.

At that conference one Ruby/Rails book author said something like; “I really like the vibe here. Everybody here is talking about making a difference, educating third world children, building better communities, and making the world a better place.” And he was setting this as a stark contrast to his experience of RailsConf where “everybody was talking about how much money they made.”

On one level it’s hard to fault the Rails conf people for this. Money does on some level validate what they’ve been doing, and it isgood to feel that kind of validation.

But, I think it’s fair to say that the Rails people have been too focused on proving something, and that has lead to a perception that many rails folks have a chip on their shoulder, or are totally focused on money as a metric of success. The extent that some elements in the Rails community have embraced this perception (as mentioned on Martin Fowler’s recent blog posting), is actually a bit frighting.

So, I think Chad is doing exactly the right thing by encouraging the Rails community to take a look at how they can improve their image. A couple days ago Chad posted a blog entry entitled “Change the world” and I hope that it makes an impact in the Rails community. I definitely see Chad Fowler many of the other members of the Rails community that I know personally as good guys, and I’d like to see the current negative stereotyping of the rails community come to an end.

I’d like to see the Rails community as a whole step up to the plate, and focus their attention and marketing efforts on new projects with altruistic goals. Turn the whold Buzz machine towards something that will really change people’s lives — replacing Java just isn’t a worthwhile goal when compared with helping to feed hungry people.

So, in the hope that a little good natured competition can spur things forward, I’d just like to mention that I think the Python community is beating the pants off of the rails community in the change the world department. Here are a couple of projects that I could think of off of the top of my head which the Python community is working on:

• Irrepressible.info — which is focused on fighting censorship
• the OLPC project — which aims to bring better educational materials to millions of underprivileged childeren around the world
• the Open Planning Project – which aims to provide tools for grass roots community improvement tools.

On another note, over the last 6 months or so Compound Thinking has been been working for Philantech on a project called PhilanTrack which takes a slightly different tack. The goal of the Philantrack project is to make it easier to manage the process of giving, receiving and reporting on grants.

The idea is that “greasing the wheels” of grant giving, and allowing non-profit organizations to focus more on doing the work, will make the nonprofits more efficient, more fun, and ultimately make the world a better place.

We may not think about it, but we geeks have a lot of individual power, and collectively we really can make the world a better place. If you’re working on a Rails or Python app that can change the world for the better, drop a comment here and let us all know.