Rails applications are more likely to encounter two types of performance problems: one is that rails executes slowly, the CPU consumes too much, and the other is a rails process memory leak. Solving both of these problems requires that you first pinpoint the problematic code before you know how to remedy the problem.
How to monitor the execution performance of rails processes
Positioning CPU high, slow execution of the rails code, is quite easy things, just need you to do a little statistical analysis of Production.log, extract the longest execution of the request, the problem is obvious. Because Production.log makes detailed statistics about the execution time of rails requests, for example:
Ruby Code
Completed in 0.00693 (144 reqs/sec) | Rendering: 0.00489 (70%) | DB: 0.00000 (0%) | 200 OK [http://www.javaeye.com/]
Completed in 0.17238 (5 reqs/sec) | Rendering: 0.10011 (58%) | DB: 0.06244 (36%) | 200 OK [http://www.javaeye.com/topic/49441?page=7]
Completed in 0.20508 (4 reqs/sec) | Rendering: 0.19373 (94%) | DB: 0.00645 (3%) | 200 OK [http://www.javaeye.com/news/1586]
So we just need to write a line of shell commands, we're done! He screened out the top 500 most time-consuming requests and saved them to Timing.log.
Ruby Code
grep "200 OK" production.log | awk '{print "ALL: " $3 " View: " $8 " DB: " $12 " URL: " $17 }' \
| sort -r | head -n 500 > timing.log
Sort of good results for example:
Ruby Code
ALL: 5.51774 View: 5.38277 DB: 0.13338 URL: [http://www.javaeye.com/wiki/topic/131966]
ALL: 5.51316 View: 5.31300 DB: 0.19400 URL: [http://www.javaeye.com/wiki/topic/145383]
ALL: 5.51311 View: 5.39321 DB: 0.11234 URL: [http://www.javaeye.com/wiki/topic/160370]
ALL: 5.51135 View: 5.37604 DB: 0.12652 URL: [http://www.javaeye.com/wiki/topic/233365]
ALL: 5.49881 View: 5.35998 DB: 0.10637 URL: [http://www.javaeye.com/wiki/topic/265217]
Which requests perform slowly, at a glance. Of course, in addition, we can monitor it in real time and display the request URL that rails is currently executing in the top Watch window.