Redmineの性能を検証した事例~ITS応答性能の調査結果と対策編を読んで #RxtStudy
第6回RxtStudy勉強会で、@akahane37さんがRedmineの性能を検証した事例を公開されていたのでメモ。
とても参考になる。
Redmineは、5人ほどの小さなチームの開発や運用のタスク管理をするのが当初の想定だったと思えるが、機能改善のおかげで、100人以上の大規模組織でも、1個のRedmineでタスク管理の運用が可能になった。
だからこそ、Redmineを末永く使えるようにするには、単なる機能要件だけでなく、検索結果の応答性能や、障害に強いか又は障害から回復しやすいかという可用性などの非機能要件も重要になってくる。
たいていの業務システムも、導入当初から数年はまともに使えて業務改善の効果も出るが、5年以上経つと、システムが重くなったりするなどの非機能要件から不満が出てくるものだ。
最近は、RedmineがSI企業の基幹系業務システムと化している所も多く、Redmineがダウンしてしまうと、開発業務に支障が出る所も多いのではないだろうか?
エンタープライズ向けの業務システムでは、非機能要件というアーキテクチャ設計がとても重要であり、しかも設計当初にきちんと考えていないと、後から修正するのはとても難しい。
上記資料で興味深い点は、Redmineの非機能要件に焦点を当てて、RedmineがIT企業の基幹系業務システムとしてどこまで使えるのか、を調査していること。
アプリケーションサーバーは、Apache+Passengerが安定しているが、Apache+Unicornの方が高速であるらしい。
他にも、一つのサーバーにRedmineやSubversionなどのツールを集中して、外部へのHTTPアクセスが増えないようにする方がよいらしい。
チケットを2万~200万件まで断続的に増やした場合、どこでボトルネックになるか、を調査している。
その調査結果では、チケットが20万件になると、全文検索が20秒かかるため、別の検索サービスなどを導入するなどの機能改善が必要になるという。
また、チケットが70万件を超えると、MySQLの起動に5分以上かかるらしいが、対応方法はある、とのこと。
そして、チケットが200万件を超えると、チケット一覧を表示する処理時間が倍以上に増えてしまうため、MySQLのBufferPoolを増やすなど、MySQLのmy.cnfを改良する必要があるらしい。
調査結果から以下の結論を出している。
(引用開始)
ITSの耐用検証(応答基準)まとめ:
ITSと連動した全文検索の解決策と、16GBのメモリがあれば200万チケットの運用に於いても日常的に使用する画面・機能において100ms前後の応答性能をRedmine2.0系で期待できる。
(引用終了)
この調査結果を読む限り、Redmineは全文検索機能がすぐにボトルネックになるが、それ以外の運用は、メモリ追加などのハードウェアのチューニングやMySQLやWebサーバなどのミドルウェアのチューニングで改善効果が見込める。
このような貴重なRedmineの事例が公開されているのはとてもありがたい。
| 固定リンク
「Redmine」カテゴリの記事
- JTCの壁を壊す「Redmine参謀本部」という戦略~現場の職人気質を活かす組織論(2026.05.19)
- 第30回東京Redmine勉強会の感想 #redminet ~古いチケット管理基盤にAIという新しい衣を被った未来(2026.05.16)
- 製造業がRedmine導入で必ず聞く3つの質問~MS Project派がRedmine導入で悩むこと(2026.05.03)
- RedmineのAI支援機能はチケット管理システムにとって重要な要件だ(2026.04.29)
- マイクロマネジメントに陥ったチケット駆動開発の罠と再生戦略 #redminet(2026.04.26)
「ソフトウェア工学」カテゴリの記事
- JTCの壁を壊す「Redmine参謀本部」という戦略~現場の職人気質を活かす組織論(2026.05.19)
- マイクロマネジメントに陥ったチケット駆動開発の罠と再生戦略 #redminet(2026.04.26)
- リプレースとアーキテクチャモダナイゼーシヨンの違いの本質は何なのか?(2026.04.08)
- アーキテクチャモダナイゼーションにおけるAMETチームの役割と責任範囲は何か(2026.03.23)
- アーキテクチャモダナイゼーションとはそもそも何なのか?(2026.03.22)


コメント