Question

I have a Resque job which pulls a csv list of data off of a remote server and then runs through the +40k entries to add any new items to an existing database table. The job is running fine however it severely slows down the response time of any subsequent requests to the server. In the console which I’ve launched ‘bundle exec rails server’, I see not print statements though the job is running. However once I hit my rails server (via a page referesh), I see multiple SELECT / INSERT statements roll by before the server responds. The SELECT/INSERT statements are clearly generated by my Resque job but oddly they wait to print to the console unit I hit the server through the browser.

It sure feels like I’m doing something wrong or not following the ‘rails way’. Advice?

Here is the code in my Resque job which does the SELECT/INSERTS

# data is an array of hashes formed from parsing csv input. Max size is 1000
ActiveRecord::Base.transaction do
  data.each do |h|
    MyModel.find_or_create_by_X_and_Y( h[:x], h[:y], h )
  end
end

Software Stack

• Rails 3.2.0
• postgresql 9.1
• Resque 1.20.0

EDIT

I’ve finally take the time to debug this a bit more. Even a very simple worker, like below, slows down the next server response. In the console where I’ve launched the rail sever process I see that the delay occurs b/c stdout from the worker is being printed only after I ping the server.

  def perform()
    s = Time.now
    0.upto( 90000 ) do |i|
      Rails.logger.debug  i * i
    end
    e = Time.now
    Rails.logger.info "Start: #{s} ---- End #{e}"
    Rails.logger.info "Total Time: #{e - s }"
  end

I can get the rails server back to its normal responsiveness again if I suppress stdout when I launch rails but it doesn’t seem like that should be necessary… bundle exec rails server > /dev/nul

Any input on a better way to solve this issue?

Answer 1

I think this answer to “Logging issues with Resque” will help.

The Rails server, in development mode, has the log file open. My understanding — I need to confirm this — is that it flushes the log before writing anything new to it, in order to preserve the order. If you have the Rails server attached to a terminal, it wants to output all of the changes first! This can lead to large delays if your workers have written large quantities to the log.

Note: this has been happening to me for some time, but I just put my finger on it recently.