addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscontroller-playcrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobegmailgooglegroupshelp-with-circleimageimagesinstagramFill 1light-bulblinklocation-pinm-swarmSearchmailmessagesminusmoremuplabelShape 3 + Rectangle 1ShapeoutlookpersonJoin Group on CardStartprice-ribbonprintShapeShapeShapeShapeImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruserwarningyahoo

Re: [ruby-99] Help Diagnosing Slow Controller Actions

From: Paul H.
Sent on: Wednesday, June 23, 2010 5:08 PM
Hi Steven,

I am not sure what > 1 second means. Are you saying that 1.87% of the pages are as high as 10 seconds or 1.2 seconds. Overall it sounds like that site isn't doing that bad. (I would still look into it, but the pages could be justifiably slow based on # queries, indexes, application logic, etc. What is the average response time?

I would do two things, the first would be to signup for new relic for the trail period. This will help you see a better big picture on whats going on from request queues to slow sql queries, etc.

Then I would take your log and find the slow actions/controllers. Then I would fire up your app on your local system and run your own benchmarks. You might also consider using a profiler (or newrelic) while your'e performing your benchmarks.

You can then look at the slow queries and add indices if needed, or benchmark the slow actions and find out which methods are taking up the time. (new relic will help a lot, but you can do it without newrelic.)

Good luck!


On Jun 23, 2010, at 4:29 PM, Steven Chanin wrote:

I've got an app running on a VPS that has about 2% of it's requests taking way longer than they should (> 1 sec).  These are random instances of requests that normally process fast (max a couple hundred ms).  I've got the production log files, but they aren't giving me much insight into why things are occasionally slow & I was hoping people on this list might be able to suggest next steps to track this down.

The app ( is running on Passenger and MySQL at railsplayground on a VPS slice with 512mb of RAM that is "burstable" to 1024.  In general, the memory used shows up in VirtualMin at about 400mb.  The machine is running a POSTFIX mail server, ssh, etc, but no other web sites or rails apps.

Looking at a sample of 4919 requests, there are 92 that took over 1 second (1.87%)

Of the 92,
26 spent more than 1 second in the DB
32 spent more than 1 second in the view (no overlap with slow db requests)
31 are redirects to session#new when the :login_required before_filter (from restful_authentication) causes a redirect [These are 3% of the times :login_required fails, the other 97% of the cases where :login_required causes a redirect, it's fast .. like between 1ms and 70 ms]

I don't see any obvious time of day pattern to when slow requests show up (so I don't think it's backup related, but I'm not 100% sure).

It's not a Query optimization problem because:
* I've looked query explains
* ABCController#action will run fast most of the time (e.g. completed in[masked]ms), but have a couple of instances that are 10-50x slower (e.g. 1000 - 10,000 ms)
* we're not dealing with lots of rows (the biggest table in the database is sub-10,000 rows)

My gut is saying that is a VPS / server config issue, but I'm not sure what to do next to get more info.  

Any help out be appreciated!

Steven Chanin
[address removed]

Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Steven Chanin ([address removed]) from Silicon Valley Ruby Meetup.
To learn more about Steven Chanin, visit his/her member profile
To unsubscribe or to update your mailing list settings, click here

Meetup, PO Box 4668 #37895 New York, New York[masked] | [address removed]

Our Sponsors

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy