Bug 848090

This seems to have something to do with eager loading in activerecord.

At pools_controller.rb:80:

Pool.includes(:deployments, :instances, :quota, :catalogs).
          list_for_user(current_session, current_user, Privilege::VIEW).
          list(sort_column(Pool), sort_direction)

Somewhere inside of this chain of calls, the process goes cpu-bound.  It's kinda hard to debug because the stack is like 100+ frames deep.  From what I can tell, it's trying to build objects for all the eager loaded records, and wire up all the inter-object relationships for them.

If instead the eager loading is removed, and the code looks like this:

Pool.list_for_user(current_session, current_user, Privilege::VIEW).
     list(sort_column(Pool), sort_direction)

The requests return in a reasonable amount of time.

This is happening on some test systems that dajo is running automation against.

This was added with the following commit:

commit bc9ef2f278a7d96ce3b7c02e072f141a04c89d87
Author: Tzu-Mainn Chen <tzumainn>
Date:   Thu Mar 22 11:27:24 2012 -0400

    BZ 802571 added eager loading and other minor efficiency fixes

It seems we have dueling scalability concerns here. The eager loading was added to address certain scalability concerns, and it is causing others.

It may be worth revisiting the original use case that led to the eager loading -- with recent changes in permissions queries, etc, the eager loading may not be needed anyway.

I'm reassigning to Tzumainn, since he added the original eager loading bits here. Tzumainn --  you're not the right one to resolve this, we can work w/ Angus to find the right person.

I have not been able to reproduce this here lately so closing this out until it shows itself again.