ChiliProject - Performance Issue with Chiliproject 3.0.1

ChiliProject is not maintained anymore. Please be advised that there will be no more updates.

We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.

Performance Issue with Chiliproject 3.0.1

Added by Markus Guske at 2012-04-23 02:25 pm

Hi,

we moved from Redmine 0.9 to Chiliproject 3.0.1 and received (next to all the great features) a huge performance issue.

I guess I eliminated the DB stuff, implementing some caches on the MySQL Server, but we see a lot of time gone in the RailsStack.

E.g.: showing an issue take 7 - 14 seconds (even if you call it directly with the number or via link)
Here is the excerpt from the log:

Processing IssuesController#show (for IP_ADRRESS at 2012-04-23 10:49:06) [GET]
  Parameters: {"action"=>"show", "id"=>"3393", "controller"=>"issues"}
Rendering template within layouts/base
Rendering issues/show.rhtml
Completed in 7672ms (View: 7625, DB: 16) | 200 OK [http://MY_LAN_SERVER/issues/3393]

Processing IssuesController#show (for IP_ADRRESS at 2012-04-23 10:52:21) [GET]
  Parameters: {"action"=>"show", "id"=>"3393", "controller"=>"issues"}
Rendering template within layouts/base
Rendering issues/show.rhtml
Completed in 14453ms (View: 13172, DB: 16) | 200 OK [http://MY_LAN_SERVER/issues/3393]

Or updating an issue with sending 2 notification emails takes incredibly long

Completed in 7516ms (DB: 94) | 302 Found [http://MY_LAN_SERVER/issues/3699]

Update 23.04.2012 - 16.33: update takes 46 seconds!

Processing IssuesController#update (for IP_ADRRESS at 2012-04-23 16:22:12) [PUT]
  Parameters: {"action"=>"update", "attachments"=>{"1"=>{"description"=>""}}, 
"id"=>"3699", "controller"=>"issues", "issue"=>{"priority_id"=>"4", 
"description"=>"THE_DESCRIPTION:::::", "done_ratio"=>"100", "estimated_hours"=>"", 
"status_id"=>"13", "custom_field_values"=>{"38"=>"", "39"=>"", "34"=>"", "35"=>"", 
"36"=>"", "37"=>"0", "42"=>"Others", "43"=>"1", "41"=>"", "4"=>"CERT", "5"=>"", 
"1"=>"", "8"=>"", "2"=>"", "6"=>"", "9"=>"", "10"=>"", "13"=>"", "18"=>"", "11"=>"", 
"12"=>"", "24"=>""}, "assigned_to_id"=>"112", "due_date"=>"2012-04-20", 
"start_date"=>"2012-03-26", "parent_issue_id"=>"3698", "tracker_id"=>"42", 
"lock_version"=>"3", "fixed_version_id"=>"2", "subject"=>"THE_SUBJECT::::"}, 
"time_entry"=>{"hours"=>"", "comments"=>"", "activity_id"=>"10"}, "_method"=>"put", 
"authenticity_token"=>"lWbekmxG5B+wIkHJ0iyY1x17nua3EYZvko3bb8JXdvE=", "notes"=>"", 
"send_notification"=>"1", "commit"=>"OK"}
Sending email notification to: MAIL_RECEIVER
Sending email notification to: 
Redirected to http://MY_LAN_SERVER:3000/issues/3699
Completed in 46126ms (DB: 62) | 302 Found [http://MY_LAN_SERVER/issues/3699]

Environment looks like:

Windows 2003 Server
launched with thin
MySQL 5.1.38
Ruby 1.8.7 pl-378

Any idea what causes the delay and where?
Any hint where to look?

Any help is appreciated.

Replies (2)

RE: Performance Issue with Chiliproject 3.0.1 - Added by Markus Guske at 2012-05-08 09:28 pm

Hi,

update: after doing some investigation, i found out: it was a recalculating issue.

What does it means:

We had one collecting issue, which was the parent for around 64 issues and these 64 were also parents each with 4 additional issues which were not simply related issues, they were time dependent to get a project plan.
Means: if we changed of one of the last child issues, it seems, that chiliproject was recalculating the whole "project" top issue and its dependents.
After we eliminated the dependency of the 64 issues to the one top parent issue, performance was back.

Remark: we used the one top parent issue strategy to simulate the target version stuff.
Now we introduced the target version and things are more simpler and faster.

~ Markus

RE: Performance Issue with Chiliproject 3.0.1 - Added by Felix Schäfer at 2012-05-17 08:13 pm

This still sounds like a lot, could you make us a "note" issue about performance of sub issues? Thanks!

(1-2/2)