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」カテゴリの記事
- 「Redmineハンドブック」は良い本です(2022.12.17)
- 第23回東京Redmine勉強会の感想~コミュニティは仲間から生まれて続く #redmineT(2022.11.06)
- 第22回東京Redmine勉強会の感想 #redmineT(2022.05.29)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- オープンソースERPパッケージiDempiereに対する派生開発手法の提案の資料が興味深かった(2022.04.24)
「ソフトウェア工学」カテゴリの記事
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- プロジェクト管理やソフトウェアアーキテクチャの問題の背後にはトレードオフが隠れているのではないか(2023.02.18)
- デブサミ2023の感想(2023.02.11)
- ChatGPTにEclipseでEclEmmaとJaCoCoからカバレッジを出力する方法を聞いた(2023.02.01)
- DDPは品質管理に役立つのか(2022.12.13)
コメント