I have a client that has a Rails app that was built by someone that
didn’t know what they were doing, at least from the standpoint of MVC,
and so rather than portioning out their business logic in different
controllers, they have a controller with hundreds of methods, totaling
60,000 lines of code. Yes, 60,000.
They are – not surprisingly – having performance problems. However
these problems could be elsewhere, there are obviously some other
problems with this code.
Before I start what will be a very painful and time-consuming
refactoring effort, I really do need to determine unequivocally that a
controller this large is really truly certainly a significant
performance problem. Yes, this should be fixed but at this point I need
to be in triage mode and know for sure.
My thinking is that perhaps every time a page is rendered, a mongrel has
to instantiate this controller and that marshalling this into RAM is
very time-consuming. Or does a controller get loaded into RAM at server
startup and then the effect is not all that substantial for each page?
Any ideas on this?
I am familiar with Ruby profiling and we are looking into that too.
Thanks.
My thinking is that perhaps every time a page is rendered, a mongrel has
to instantiate this controller and that marshalling this into RAM is
very time-consuming. Or does a controller get loaded into RAM at server
startup and then the effect is not all that substantial for each page?
Any ideas on this?
I’m not familiar with Mongrel-based hosting, but in Passenger classes
are
cached in memory when loaded and instantiated from that. The cost of
instantiating a new object shouldn’t be that onerous (even if you have a
zillion methods) as it’s only a pointer to the class at that point and
an
instance data created during instantiation.
I am familiar with Ruby profiling and we are looking into that too.
Personally I’d recommend testing it on a Mac and using DTrace to get a
really good insight in to where it’s spending it’s time. I’ve had a lot
of
success with that in the past.
Cheers,
Andy
Personally I would get hold of the log files and see what methods (or
at least controller and actions) are being called the most and see
what sort of time they are taking. The users might be able to tell you
what appears to be the slowest parts of the system.
Then I would concentrate on those parts of the 60,000 lines of code
that people are actually complaining about.
You don’t want to be trying to refactor 60,000 lines of code in one
go. Refactor around the really bad parts, cleaning up as you go.