Rails 3.2 RC1: Faster dev mode & routing, explain queries, tagged logger, store

http://weblog.rubyonrails.org/2011/12/20/rails-3-2-rc1-faster-dev-mode-routing-explain-queries-tagged-logger-store

by aaronbrethorst • 15 years ago

185 50 15 years ago

weblog.rubyonrails.org

Good to see that rails developers are progressively seeing the database as a powerful tool and not just as flat files with funny accents.

jarin• 15 years ago

Uh oh, I haven't even updated my clients to Rails 3.1 yet. Definitely not good to fall behind more than a major point release or two with Rails. I have a very old client running Rails 2.3.x and it's always a pain when they need the occasional update and Rake doesn't even work anymore.

rohitarondekar• 15 years ago

As I understand it, a lot of work has been put into Rails 3.x series so that it is easier to upgrade your apps.

It should be a lot easier to go from 3.0 to 3.1 or 3.2 and hopefully from 3.0 to 4.0.

moe• 15 years ago

I do hope they improve their policy on regression-tests and upgrade instructions. 3.0 -> 3.1 wasn't very smooth for me, the bugs were just more subtle.

My favorite bug during the upgrade: Someone decided (long ago) it'd be a good idea to store a Marshalled object in the session-cookie. One class serialized therein disappeared in Rails 3.1. Result? Any and all requests with a session-cookie bomb out with an unmarshall error.

tldr: Make sure to rename your session cookie before rolling out the upgrade. This logs out all users but is still more desirable than the alternative...

elektronaut• 15 years ago

I feel your pain, I have a bunch of legacy 2.2 and 2.3 apps.

I moved all dependency management from config.gem over to Bundler, and haven't had a dependency issue since.

nirvdrum4• 15 years ago

I wish I was still on 2.3. I made the jump and am now running 3.1, after putting off upgrading for so long. I bit the bullet because most plugins simply don't backport bug or security fixes. But hardly a day goes by that I don't wish I was still on 2.3.

ddagradi• 15 years ago

It sounds like you're not using rvm and gemsets (or a similar tool) for your Rails 2.3.x sites. Rake should never "stop working".

http://beginrescueend.com/

mechazoidal• 15 years ago

Unless you're on a platform where you can't get gcc >4.0, so RVM is helpless, and you're stuck with just bundler. Then the rake/cron nightmares come..

kposehn• 15 years ago

Key/Value storage built in?

I love rails :)

Corrado2• 15 years ago

I've really noticed quite a bit of speed improvement lately with Ruby 1.9.3 and now Rails 3.2.0-rc1, at least in my development environment. It's a good thing too because lately I have been thinking back fondly of the good old Rails 2.x days when you could restart the development environment without flinching. With the latest incarnation of these two tools I love the Rake command again. :)

Now, if we could just get someone to commit the fix for the debugger under Ruby 1.9.3. Not being able to debug, or at least having to work too hard at it, is really a drag on my productivity and is keeping me from moving to the newer faster stuff everywhere. Come on Mr. Moseley, release ruby-debug-base19 v0.11.26 already!

ascendant• 15 years ago

I can only hope that running my app in dev mode in 3.2 won't bleed memory 40 MB per request. I have no such issues in production environment and it makes testing/debugging a royal pain.

snprbob862• 15 years ago

It's probably not Rails itself...

I had a similar issue, which turned out to be a bad Rails plugin, which maintained a few unnecessary pointers to my model classes. The small plugin caused a 20+MB per request leak in development. I rewrote the piece of functionality I needed from the offending module & the issue went away entirely.

Sadly, there isn't really decent memory profiler support to help you track it down. I found the issue by running `git bisect run` with a little script which restarted the server, beat on it a bit with `ab` and then printed memory usage with `ps`. Took me about 10 minutes to track it down to the exact offending commit.

sandGorgon2• 15 years ago

does this fix the abominably slow development with the asset pipeline (without the gems needed to hack it and speed it up)?

Basically, can someone give me a way back into pre-3.1 asset pipeline slowdown ?

tmeasday2• 15 years ago

Can you be more specific? Are you talking about rails startup time or SASS compilation? Or something else?

aubergene• 15 years ago

I found it was really slow when assets were in debug. I generated a new rails app and copied the config from there and then merged in the settings from the old project I needed and it was super fast.

andyl• 15 years ago

I used this command to get the debugger working on 1.9.3-p0.

    bash < <(curl -L https://raw.github.com/gist/1333785)

keeran• 15 years ago

Nice tech talk about the thinking behind the new router from Aaron Patterson (@tenderlove) at MagRails.

http://www.youtube.com/watch?v=sEbobUPqhL4

cliftonk• 15 years ago

https://github.com/rails/journey is the code for his router

Great talk, also.

burke4• 15 years ago

In my project, "rake environment" took 11.5 seconds on rails 3.1.x, and 8.7 seconds on rails 3.2. (1.9.3.p0 for both).

I'm quite happy about this, as the initial development boot time is what's been bothering me most lately.

jhealy2• 15 years ago

We see ~20% improvement with the same upgrade (on 1.9.3p0).

8.5s to 6.6s on my laptop (with SSD). Nice!

Fluxx• 15 years ago

IMO, 6.6 seconds to boot the app is still too slow, but it's certainly progress. :)

wfarr2• 15 years ago

Seeing about 25% speedup here with just the Rails 3.2 RC1.

Combined with rspec-rails 2.8.0.rc2 (which includes some Rails 3.2-related changes), I saw my test suite go from ~2.5s (Rails 3.2.0.rc1 w/ rspec 2.7.x) to ~0.43s (Rails 3.2.0.rc1 w/ rspec 2.8.0.rc2).

Ruby 1.9.3p0 across the board.

burke4• 15 years ago

Not mentioned anywhere is that the PostgreSQL adapter now supports using the Schema Search Path without fistfuls of bugs and oversights.

I'm using schema separation for a multitenant application, and it looks like I'll be able to remove at least 4/6 hacks to make rails support that functionality.

ryanbigg• 15 years ago

Could you elaborate?

burke4• 15 years ago

Sure. Basically, I have a schema called template_tenant, and a table public.tenants (ie. in the public schema). For each record with id n in the public.tenants table, I have another schema tenant_n cloned from and kept in sync with the template_tenant schema.

The result of this is that I have dozens of tables duplicated across n schemas. In Rails 3.1, the Postgres query cache, exec cache, and the identity map do not account for this, nor does table_exists?, and the connection pool would often check out a new connection without preserving the search path.

In Rails 3.2, most of these are fixed. The exec cache, query cache, and table_exists? now observe the search_path properly, and I believe the connection pool behaves better, though I haven't had time to confirm that. The identity map still doesn't understand, which I've filed an issue for: https://github.com/rails/rails/issues/4044

I'm really happy with this pattern for multi-tenant apps. It gives me a lot more confidence that no data leaks will happen than scoping queries, and the performance increase is significant with large datasets (unless of course, for some reason, you need to aggregate across tenants). It's nice to see rails supporting this better.

The sixth patch I had hacks support for iterating over multiple schemas to migrations. I add "schema_set :public or :tenant" to the top of my migration, and it runs either once on the public schema, or n+1 times on my template_tenant schema and my tenant_X schemas. It wouldn't make sense for this part to be in rails proper at the moment.

marcalc3• 15 years ago

Could you? :)

marcalc3• 15 years ago

Also, if it is not much to ask, I know this is not the topic, but could you describe how you make this kind of separation? I have the same requirements for isolation and your experience in the matter would be valuable. :)

sant0sk1• 15 years ago

Awhile back, I blogged how to go about this. Some of the hacks will not be needed for Rails 3.2, but the concepts are the same:

http://blog.jerodsanto.net/2011/07/building-multi-tenant-rai...

burke4• 15 years ago

I haven't read sant0sk1's post -- it's probably the same idea -- but I gave an ultra-high-level overview in another comment: http://news.ycombinator.com/item?id=3374294

EDIT: This is my migration hack: https://gist.github.com/1f5e67b018d304dd1198 . Most of the SchemaUtils/Schema stuff is just wrappers around setting the schema_search_path.

Rails 3.2 RC1: Faster dev mode & routing, explain queries, tagged logger, store

Related Stories