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のバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
- ウクライナのRedmine開発者が作ったRedmineテーマやプラグイン(2024.06.18)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- Redmineで持ち株管理する事例(2024.04.21)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
「ソフトウェア工学」カテゴリの記事
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
- マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか(2024.01.02)
- 「ソフトウェアアーキテクチャ・ハードパーツ」の情報リンク~マイクロサービスの設計技法の課題は何なのか(2023.11.12)
コメント