Performance Issues - With produces

We seem to be having an issue with the periodical on this project.

There is a small portion of the application which needs to be updated whenever a user interacts with a hardware device connected to the machine.

Our initial take on this was to have a periodical which would poll the server every '0.5' seconds to figure out if the event had happened. Very simple indeed.

Until we were hit with some insane performance issues !!

Initially we saw that all the development machines, but one, seemed to be hogging more and more memory as time passed by, and eventually some of them just froze up. After some poking around the only difference we could see was that on that 'one' machine we had ruby compiled for the i386 whereas all the others seem to be i686 (thats what ruby -version told us). So we went ahead and installed the precompiled i386 version of ruby on some machines and that seemed to solve the issue for sometime (still dont understand why)

Anyways. The issue resurfaced and today we went about trying to fix it.

Initially we thought that instead of doing a Pull from the client we should Push this information from the server. The basic idea behind a Push from the server being that once a connection is opened to the server by a client, the server keeps this connection open by never closing it and periodically (or whenever the need arises) sending information to the client.

So spent a bit of time today reading up on how to push information from the server and trying to implement it with Rails. There are quite a few interesting examples on how to do this. But we ended up digging into the Rails code to figure out how rendering actually works in rails and figured that it was not easy to bypass the rails way of doing things. Rails prevents us from doing this kind of stuff(keeping the connection open and rendering continuously) because of the Double Render issue. So we tried to get the response object and tried to work with the output stream on the response object. But dipping into the Rails code we figured that the output stream is just a StringIO and later the rails actually picks up the data and uses it to create the body and header and pushes this info to webrick.

In the end found this link. Basically it mentions that in the development mode the rails app reloads itself on every request.

Daaam !! Had forgotten about this. So just tried to run the application in production mode and things seem to be fine now !!

whew ...

Found another Web server mongrel. This seems to be much faster than webrick. It consumed half the memory that Webrick was consuming and the app seemed snappier when using mongrel.

Calling methods on another Controller in Functional Tests

Today while trying to write a functional test in our rails app we came across an issue wherein the session had to be setup in a particular manner before we could actually test this action we were interested in.

post :delete_flower

so we wanted delete_flower action to be called on the FlowerController. But for the test to pass we needed some action on GardenController to be called (so as to mimic what would happen on the GUI)

but get and post methods are called only on the current controller. So we wrote up this helper method in the test_helper.rb file

class Test::Unit::TestCase
 def switch_controller(klass)       
  old_controller = @controller       
  @controller = klass.new       
  yield
  @controller = old_controller
 end
end

So in our code we could do something like

def test_delete
 switch_controller(GardenController) do
   post :plant_flower
 end
 post :delete_flower
 assert_no_flower_in_garden
end


[Updated later] - Just saw that they have added the concept of an Integration Test for the next release of rails.
So Looks like all this might not be necessary !!