How we struggled with performance problems in Redmine. Who is to blame and how to help?

Of course, the article is not quite named. In pure Redmine, there are no particularly big performance problems. But we, in the process of developing a large number of plug-ins, these problems were easily introduced.

Therefore, the article will tell you how to understand the reason for the slow work of a particular function of the Redmine plug-in and what tools can help with this. Many tips, of course, may concern not only Redmine itself, but also Rails applications as a whole.

The symptom of performance problems is always the same - this is an angry user, screaming, cursing your software and possibly you personally.

')

Rack Mini Profiler

Most often, problems with the long opening of any page are related to SQL queries. These can be simply long-running SQL queries or cyclic queries caused by the features of the Active Record mechanism in ROR. In any case, the Rack Mini Profiler is a mega-useful thing for analyzing performance problems in Redmine.

Rack Mini Profiler is a small gem that is installed in a couple of commands and shows in almost real time what requests were made during the page loading process, and how much time each request took. To analyze performance problems, this thing is simply indispensable.

In the early stages of Rails programming, I had the persistent feeling that Ruby on Rails was such a thoughtful framework that, using Active record, I simply chose the data I needed, thinking that the developers of the framework took care of everything else.

As a result? I spawned a large handful of circular SQL queries. With the growing number of users, some pages began to open for a very long time.

Rack Mini Profiler allows you to very quickly find the reason for the long opening of the page for a particular user. Here's how, for example, it might look like if you do not add “includes” to the “active record” - construction.

The total number of SQL queries in itself suggests suspicion:



If you look at more detailed statistics, you can understand that when opening a page cyclic SQL queries are generated and this problem needs to be fixed.



Even after when a deeper understanding of Active record in Rails came, periodically, cyclical queries prolazili to the working server. Therefore, we decided that the tester, while checking the task, should necessarily analyze the information from the Rack Mini Profiler for the presence of long and cyclic requests.

Plugin for Redmine - "RmPlus DevTools"

Rack Mini Profiler is enabled by default in the development environment and turned off in production. But often it is necessary to analyze the performance situation in the production-environment and for a specific user, so we wrote a small plug-in for Redmine, which connects the Rack Mini Profiler to the production-environment Redmine and allows you to connect profiling only for a specific user - Redmine Dev Tools .



Also, this plugin connects Oink jam (I’ll talk about it a little later) and gives an opportunity to conduct more convenient development of plug-ins for Redmine in the development-environment: there is no need to reload the web-server in order to apply the changes in the JS-files on the page.

"OINK"

Oink is another super-useful jam for analyzing performance problems. It helped a lot when memory started to leak on our working server. One of the processes of Rails for unknown reasons, was eating more than a gigabyte of RAM and hanging the whole Remine.

As a result: a bunch of calls to the phone, goosebumps and a slight feeling of powerlessness.

Oink allows you to analyze which controllers and actions of Rails eat up memory by setting a threshold value. This statistic sheds light on the source of the problem, after which the elimination of the source of the problem becomes more trivial.

oink --threshold 50 /usr/share/srv-redmine/redmine-2.5/log/oink.log



Something like that! I hope my article will be useful. It would be very useful to me in due time.