Redmineチューニングの実際と限界 - Redmine performance tuning

Redmineチューニングの実際と限界 - Redmine performance tuning

Download:
* Setting_paramaters_for_Redmine_Performance_Tuning.txt
https://gist.github.com/akahane92/771f9a52d81af9864dd8
* Slide PDF
https://goo.gl/EWLRkW

Transcript

  1. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved Redmineチューニングの

    実際と限界 〜200万チケットでもサクサクなRedmineの作り方〜 第1版 2015年5月16日 第 8回 Redmine.Tokyo 第2版 2016年3月 5日 第14回 RxTstudy 第3版 2017年8月26日 第17回 Redmine大阪 第4版 2019年3月 9日 第19回 Redmine大阪 株式会社島津ビジネスシステムズ 赤羽根 州晴 kakahane@sbs.shimadzu.co.jp
  2. ありがとう。 Thanks a lot. Danke schön. Merci beaucoup. 2

  3. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 話者紹介

    赤羽根 州晴(@akahane92) 島津製作所 業務系システム子会社 ・ソフトウェア開発技術者 ・内部統制 ・基盤技術標準化 ・装置開発支援 (現在) 3 社外活動 (運営に関与) ・Redmine大阪 社外発表 ・2013 JaSST関西 経験発表 ・2014 SQiP 経験論文(査読付) ・2016 IPA/SEC 事例論文(査読付) 書籍 ・2015 Redmine実践ガイド(寄稿著者)
  4. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ソフトウェア品質シンポジウム

    2014 経験論文 4 このシンポジウムは35年の歴史を持ち、 ソフトウェア品質に関しては国内最長 https://www.juse.jp/sqip/symposium/archive /2014/day2/files/ronbun_A3-4.pdf
  5. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved IPA/SEC

    先進的設計・検証技術 2016 事例論文 5 独立行政法人情報処理推進機構 ソフトウェア高信頼化センター 「先進的な設計・検証技術の適用事例報告 書 2016年度版」に採録公開(予定) ~IoT時代を見据えたソフトウェア開発の 信頼性確保を実現したベストプラクティス の事例を紹介~ 2016年度 公開資料 https://www.ipa.go.jp/sec/reports/201 70302.html
  6. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved お話しすること

    6 1)200万チケットでもサクサク動くRedmineの全レシピ* 2)Redmine 2.6 を 4.0 へUpdateすると平均で◦◦% 速くなる 3)Ruby2.2 を 2.5, 2.6 へUpdateすると平均で◦◦% 速くなる 4)HDDをSSDにすると環境により平均で◦◦% 速くなる 5)非索引型の全文検索は◦◦~◦◦万チケットで性能限界に到達 するが、Fulltext-Search-Plugin の導入によって◦◦倍速くなり、 200万チケットの環境では平均◦◦秒で全文検索できる 6)Redmine全文検索の機能の追加開発とオープンソース化 7) Redmineチューニング事例 9種 *全レシピ: 設定値の一括ダウンロードはこちら (GitHub Gist) Download: Setting_paramaters_for_Redmine_Performance_Tuning.txt https://gist.github.com/akahane92/771f9a52d81af9864dd8
  7. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved お話ししないこと

    7 1)大規模な並列トランザクション 2)DBMSチューニングの秘境探索
  8. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ご注意

    8 本発表の内容には様々な設定が含まれていますが、 ご利用は自己責任でお願い致します。 参考になさった場合に生じたいかなる損害も補償できません。 あらかじめご了承下さい。
  9. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 教えて下さい

    9 Redmine ・遅いと感じている方は? ・性能チューニング経験は? ・使用しているDBMSは? (Postgresql、MySQL、SQLite、MicrosoftSQL、他) Eric Peacock https://www.flickr.com/photos/evilpeacock/6365513881/
  10. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次

    10 第1部 背景と要求 第2部 チューニングの基本 第3部 ベンチマーク 第4部 全文検索機能の拡張 第5部 性能改善事例集 第6部 まとめ 10
  11. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 株式会社

    島津製作所 2018年3月31日現在 創 業| 設 立| 資 本 金| 従 業 員 数 | 3,765億円 (2018年3月期) グループ売上高| 社 是|科学技術で社会に貢献する 経営理念|「人と地球の健康」への願いを実現する 11 11,954名 (連結) 明治8(1875)年 大正6(1917)年 約266億円
  12. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事業領域

    産業機器 航空機器 医用機器 分析・計測機器 12
  13. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 課題管理システム(ITS;

    Issue Tracking System) 1. 研究開発型の製造業における製品・システムの開発・保守の現場では、大 量の情報と知識を多人数で共有し、長期間にわたって扱っていかなければ ならない。しかし、その実現と維持は容易でなく「忘却、変容、誤認、抜け 漏れ」が生じて効率と品質が低下する原因の一つとなっている。 2. 数多くの人が円滑に協業するには、大量の情報と知識をうまく扱うた めの専用の仕組みが必要となる。どのように情報と知識を扱えば人間 の有限能力を補完・支援して効率を向上させ、本来なすべき「思考と 創発」に専念できるのか。 3. 島津製作所と島津ビジネスシステムズでは、課題管理システム(ITS)と 改版・構成管理システム(VCS)を中心とした製品開発関連情報の知識基 盤を現場に定着させることで問題を軽減すべく、関連部門に広く導入 して利用している。 13 事例要約
  14. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 【問題】装置、ソフトウェアといった製品開発と保守の現場で

    は、製品数の増加や特注品・顧客別派生品といった保守対象の 累積や、第三者検証への対応工数の増加に悩まされている。 【原因】製品種類と関係者数の増加、保守対象規模の拡大に対 して、組織内情報流通の導線設計、及び開発関連情報の知識基 盤整備が追いついていない。 【対策】製品開発に関連する情報の知識基盤を整備し、組織内 情報流通の導線設計を実現するOSSツールセットを2009年に 導入した。 【結果】製品開発・保守業務の効率と品質の向上、第三者検証 に役立つ追跡可能性の水準向上といった改善効果を得た。 14 事例要点
  15. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例

    15 島津製作所グループ 業務システム 情報系 子会社 委託 IT全般統制 ISO 内部統制 省庁監査
  16. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例

    16 島津製作所グループ 業務システム 情報系 子会社 委託 IT全般統制 ISO 内部統制 省庁監査 複数の統制・認証に対応 大量の記録が必要
  17. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例|背景モデル

    17 要 件 結 果 業務用ITシステムの全般的な管理記録は 内部統制や各種認証(ISO, ISMS, 省庁監査)の 要求に答えなければならない •記録と整合 •精査と承認 •追跡可能性 •目的合理性 •品質管理 •セキュリティー
  18. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例|背景モデル

    18 課題 3 課題・要望 問合せ受付 調査と確認 状況報告 方針決定 対処と確認 結果報告 時 間 課題 2 変更 問合せ受付 調査と確認 状況報告 方針決定 対処と確認 結果報告 時 間 課題 1 トラブル 問合せ受付 調査と確認 状況報告 方針決定 対処と確認 結果報告 時 間 複数 ユーザー 複数 ユーザー 複数 ユーザー 複数 ユーザー 複数 ユーザー 複数 担当者 C事業部 B事業部 A事業部 X System Y System Z System 関係者増加 / 事案多様化/システム増加・分散 m : n : i
  19. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例|業務システムの運営状況

    19 業務システム 100種 利用者 7000人 事案 56000件 改版(コミット) 20000回 1700 KLOC 開発運用 200人 /年 /年 /年 自動生成コード含む 7~20年超
  20. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例|現象と問題の要約(8種)

    20 # 現象 問題 1 人の記憶が頼り「生き字引き」 記憶は不確かで、容易に消滅 2 開発作業単位ごとの管理で情報が「お蔵入り」 再利用が難しく作業コストが回収困難 3 詳細な経緯や背景は担当者のMail-Boxに埋没 検索できず、異動や離職で消滅 4 製品構成や、組織の壁が情報流通を阻害 情報の共有不足で不具合、障害が増加 5 外部委託契約の長期化。担当者間の引継ぎ不足 実装・変更の経緯が不明 後任の保守効率が低下 6 記録の分散により、情報の横断検索が困難 仕様変更のインパクト分析が困難 過去経緯の不明が品質低下の温床 7 Excelなどの汎用媒体だけでは業務を表現できない 情報の欠落、業務効率の低下 8 製品を取り巻く規制の強化によって統制・ 監査・査察の対応負担の増大が予想される 業務効率の低下、コストの上昇 製品・システム開発保守の現場は、さまざまな問題に悩まされている
  21. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例|解決策

    21 統合管理 全面導入 Issue Tracking System
  22. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例|知識基盤

    (情報容器=チケット) 22 作成者 担当者 関係者 経緯 意志決定 履歴 資料 成果物 チケット 1チケット ≒ 1クリアフォルダ
  23. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例|事案関係モデル

    5.6万件/年 2万コミット/年 /年 関係性 23 記憶の消滅 × 二次元 Excel 表現できる…何か ?
  24. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例|事案関係モデル

    5.6万件/年 2万コミット/年 /年 関係性 24 記憶の消滅 二次元 Excel ITS ×
  25. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例|ITS導入の全体像

    25 Project A 問合せ 要望・課題 障害・バグ タスク Project B 問合せ 要望・課題 障害・バグ タスク 課題管理システム (ITS) 版数管理ツール ▪日常業務に浸透 •トータルで負担減少 •状態の掌握が容易 •コミュニケーション促進 ▪トレーサビリティー 一意性 永続的な 連鎖性 履歴追跡性 ▪変化への適応 状況変化を記録し追従 後々の参照が容易に SVN
  26. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例|放置チケット対策の定着

    26 週次ミーティングで、 積極的にチケット完了 ITSを使った会議
  27. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 27

    ユ ー ザ ー 数 プ ロ ジ ェ ク ト 数 Project数 200 User数 488 調査日 2019/1 0 50 100 150 200 250 300 350 400 450 500 0 50 100 150 200 250 2010 2011 2012 2013 2014 2015 2016 2017 2018 プロジェクト数 ITSユーザー数 事例|プロジェクト、ユーザー数の経年変化 名
  28. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    10 20 30 40 50 60 70 80 90 100 0 10,000 20,000 30,000 40,000 50,000 60,000 2010 2011 2012 2013 2014 2015 2016 2017 2018 Ticket発行数 完了率 近似曲線(線形) 事例|チケットの発行数と完了率 28 調査日 2019/1 完了率 87% → 93% 累計 34万件 55,800/年 4,600/月 % 完 了 率 チ ケ ッ ト 発 行 数
  29. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    10 20 30 40 50 60 70 80 90 100 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 2010 2011 2012 2013 2014 2015 2016 2017 2018 完 了 所 要 日 数 の 平 均 完 了 所 要 日 数 の 分 布 6ヶ月以上 6ヶ月 3ヶ月 1ヶ月 2週間 1週間 1日 平均完了日数 事例|完了所要日数の分布と平均 調査日 2019/1 日 2012年 84日 2015年 51日 2018年 24日
  30. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    100 200 300 400 500 600 700 800 900 1,000 0 10,000 20,000 30,000 40,000 50,000 60,000 2010 2011 2012 2013 2014 2015 2016 2017 2018 チケット発行数 説明欄文字数(平均) 近似曲線(線形) 事例|チケット説明欄の文字数変化 30 2011年 529文字 2018年 725文字 調査日 2019/1 累計 2016年 2億7千万文字 2018年 3億6千万文字 文字 チ ケ ッ ト 毎 の 記 録 文 字 数 チ ケ ッ ト 発 行 数
  31. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    0.2 0.4 0.6 0.8 1 1.2 1.4 0 10,000 20,000 30,000 40,000 50,000 60,000 70,000 2010 2011 2012 2013 2014 2015 2016 2017 2018 チケット発行数 添付ファイル数 事例|添付ファイル数の経年変化 31 ファイル 調査日 2019/1 累積 2017年 26万3千 ファイル 2018年 35万8千 ファイル チ ケ ッ ト 毎 の 添 付 フ ァ イ ル 数 チ ケ ッ ト 発 行 数 / 添 付 フ ァ イ ル 数
  32. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例|チケット関係性の経年変化

    32 関係性カウント 線をカウントする 例)3カウント Ticket Ticket Ticket Ticket 関係記録数 2011年 11% 2018年 23% 調査日 2019/1 0% 5% 10% 15% 20% 25% 30% 0 5 10 15 20 25 30 35 40 2010 2011 2012 2013 2014 2015 2016 2017 2018 関 係 保 持 割 合 チ ケ ッ ト 発 行 数 の 累 計 / 関 係 数 の 累 計 万 チケット発行数累計 関係数累計 関係保持割合 線形 (関係保持割合)
  33. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    20 40 60 80 100 120 140 160 180 200 0 500 1,000 1,500 2,000 2,500 3,000 3,500 4,000 4,500 2010 2011 2012 2013 2014 2015 2016 2017 2018 完 了 所 要 日 数 平 均 障 害 ・ バ グ チ ケ ッ ト 数 障害・バグチケット数 完了所要日数平均 事例|障害・バグチケット数と完了所要日数の平均 33 調査日 2019/1 日 所要日数平均 2011年 172日 2015年 86日 2018年 27日 2011年 No Ticket, No Commit 開始
  34. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    20 40 60 80 100 120 140 0 10,000 20,000 30,000 40,000 50,000 60,000 2011 2012 2013 2014 2015 2016 2017 2018 障 害 ・ バ グ チ ケ ッ ト 密 度 チ ケ ッ ト 発 行 数 チケット発行数 障害・バグチケット発行数 障害・バグチケット密度 障害・バグチケット密度 (Spike除去) 線形 (障害・バグチケット密度 (Spike除去)) 事例|「障害・バグ」チケット密度 34 2012年 94件/KT 2018年 44件/KT 調査日 2019/1 件/KT (Kilo Ticket)
  35. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例概要|監査手続の定性評価

    35 【例示】「全てのIT統制対象システムにおいて、任意の 6ヶ月間に発生した全ての変更事案の中から、設計書と プログラムの両方、或いはいずれかを変更し、かつ、 データ強制変更を伴う事案の一覧を提出。ここから25 件をサンプリングし承認行為を示す証憑・証跡を提出」 3時間以内 複数人がかりで 2〜3日
  36. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例|まとめ

    36 統制実現 コスト低減 属人性軽減 品質, CS向上 業績貢献 【経営要求】 【現場要求】 現業務を表現可能 入力コストに見合う いつでもどこでも 素早く見つかる 休みやすい 【管理手法】 【統制要求】 IT全般統制 ISO 省庁監査 一意識別 ↓ 関連維持 ↓ 追跡可能 ↓ 信頼可能 現場の利益を動機とする 部分最適型の行動規範 が、結果として経営要求 を満たす統合情報基盤と して、全体最適型の均衡 を得た
  37. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例|まとめ

    37 1)100種の業務システムを200人が運用する現場 2)IT統制に対応するため高水準の管理品質を維持 網羅性は必達(全員が全情報を入力し続ける) 3)文房具:常にサクサクの応答性能と盤石な安定性 4)運営のための余力は皆無。省力化の徹底と、 安定性・信頼性の同時成立が不可欠
  38. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次

    38 第1部 背景と要求 第2部 チューニングの基本 第3部 ベンチマーク 第4部 全文検索機能の拡張 第5部 性能改善事例集 第6部 まとめ 38
  39. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本

    39 図引用元: http://ja.wikipedia.org/wiki/ボトルネック概念図.png 電子計算機 ネットワークシステム ボトルネックの 発見と解消
  40. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本

     ボトルネックはどこか? 40 # 対 象 対 策 例 1 通信 狭帯域を回避 Ethernet 2 情報量 圧縮 HTML, Text 3 電子計算 再処理を回避 多段キャッシュ 4 永続化 高速装置へ置換 HDD 5 アルゴリズム 算法選択による 計算量削減 Sort, Index, GC
  41. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本

     対策1 狭帯域通信を避ける 41 Ethernet等の 低速通信 2M , 10M , 100Mbit / 秒 経路上の最も狭い帯域
  42. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved Local

    Loopback adapter 同一OS内のTCP/ UDP/ Socket 通信 チューニングの基本  対策1 狭帯域通信を避ける 42 狭帯域 6→3
  43. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本

     対策2 情報量の圧縮 43 HTTP/1.1 Compression 情報量 1/4 ~ 1/10 最大10倍速
  44. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本

     対策3 再処理回避 44 Server Pass enge r RAID OS FS NW Ruby Rails Redmine DBMS HTTP Reverse Proxy Client Browser JavaScript / DOM OS FS NW
  45. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本

     対策3 再処理回避 45 Server Pass enge r RAID OS FS NW Ruby Rails Redmine DBMS HTTP Reverse Proxy Client Browser JavaScript / DOM OS FS NW ㋖ ㋖ ㋖ ㋖ ㋖ ㋖ ㋖ ㋖ ㋖ ㋖ ㋖ ㋖ ・潤沢なメモリ ・多段キャッシュ
  46. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本

     対策4 永続化 46 * 情報の永続化 「電源をOFFにしてもデータが消えないようにすること」 Server Pass enge r RAID OS FS NW Ruby Rails Redmine DBMS HTTP Reverse Proxy 情報の永続化* SSDの登場 劇的な速度向上
  47. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本

     対策5 算法選択による計算量削減 47 算法の選択による 速度向上* Sort, GC, Index * 算法の変更によって計算処理量を減らし、より少ない時間で同一の処理を実施する Server Pass enge r RAID OS FS NW Ruby Rails Redmine DBMS HTTP Reverse Proxy
  48. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本

     チューニング要点 48 Passenger6.0 OS CentOS7 (64bit) Ruby 2.6 Rails5.2 Redmine 4.0 DBMS MySQL 5.7 HTTP Apache 2.4 Memory 4〜16GB CPU 4〜6 Cores VMware (可用性、信頼性) VCS Subversion 1.9 HTTP Reverse Proxy --- :8 Key Points Network
  49. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本

     チューニング要点 49 Passenger6.0 OS CentOS7 (64bit) Ruby 2.6 Rails5.2 Redmine 4.0 DBMS MySQL 5.7 HTTP Apache 2.4 Memory 4〜16GB CPU 4〜6 Cores VMware (可用性、信頼性) VCS Subversion 1.9 HTTP Reverse Proxy --- :8 Key Points Network Redmine本体は変更しない 安定、安全、信頼
  50. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次

    50 第1部 背景と要求 第2部 チューニングの基本 第3部 ベンチマーク 第4部 全文検索機能の拡張 第5部 性能改善事例集 第6部 まとめ 50
  51. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク

    51 【背景】 ・年間50,000チケット以上を起票 ・業務の中心にITS(Redmine) ・処理遅延や障害停止の回避は必須要件 【2012年10月】 ・ITSの業務活用が急拡大(10万チケット越) ・200万チケットまでの動作を先行して確認 ・問題を洗い出して対策 【2015年5月、2016年3月、2017年8月、 2019年1月】 ・2012年の予測値と、最新の実績値を比較 ・Redmine, Ruby, Rails, H/Wの変化 ・再度、性能ベンチマークを計測して最適解を選ぶ
  52. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク

    52 “サクサク”の 基準
  53. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク

    53 画面応答時間の基準*とは? 100ms 直接操作している一体感 1000ms 遅延を感じつつも軽快 10000ms 集中限界、進捗表示必須 * 参考文献 Jakob Nielsen (1993). Response Times: The 3 Important Limits http://www.useit.com/papers/responsetime.html Miller, R. B. (1968). Response time in man-computer conversational transactions. http://theixdlibrary.com/pdf/Miller1968.pdf
  54. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク

    54 画面応答時間の基準*とは? 100ms 直接操作している一体感 1000ms 遅延を感じつつも軽快 10000ms 集中限界、進捗表示必須 * 参考文献 Jakob Nielsen (1993). Response Times: The 3 Important Limits http://www.useit.com/papers/responsetime.html Miller, R. B. (1968). Response time in man-computer conversational transactions. http://theixdlibrary.com/pdf/Miller1968.pdf Redmineは文房具
  55. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク

    55 実績値
  56. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク|実績値

    56 Redmine月間アクセス数*の経年変化 * 9年分のApache アクセスログに記載されたURI - 2019年1月 累計:2800万 月間:42万アクセス 調査日 2019/1 0 500 1,000 1,500 2,000 2,500 3,000 0 10 20 30 40 50 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 万 万 月平均 アクセス数累計 月 間 ア ク セ ス 数 累 計 ア ク セ ス 数
  57. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク|実績値

    2017 8年間の運用結果*を集計 57 統計要約 最小値 : 1 第1四分位点 : 73 中央値 : 193 平均値 : 396 第3四分位点 : 317 最大値 :9562551 100ms 31% 200ms 20% 300ms 21% 400ms 10% 500ms 600ms 700ms 800ms 900ms 1000ms 1000ms超 5% 100ms 200ms 300ms 400ms 500ms 600ms 700ms 800ms 900ms 1000ms 1000ms超 * 8年分のProduction.logに記載された処理応答時間 (Redmine <-> DB) - 2017年8月 調査日 2017/8 ・1443万回の処理 ・半分が200ms以下 ・95% が1秒以下 ・中央値193ms(median)
  58. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 100ms

    49% 200ms 21% 300ms 13% 400ms 6% 500ms 600ms 700ms 800ms 900ms 1000ms 1000ms超 3% 100ms 200ms 300ms 400ms 500ms 600ms 700ms 800ms 900ms 1000ms 1000ms超 ベンチマーク|実績値 2019 9年間の運用結果*を集計 58 統計要約 最小値 : 0 第1四分位点 : 35 中央値 : 112 平均値 : 295 第3四分位点 : 239 最大値 :9562551 ・2365万回の処理 ・半分が100ms以下 ・97% が1秒以下 ・中央値112ms(median) * 9年分のProduction.logに記載された処理応答時間 (Redmine <-> DB) - 2019年1月 調査日 2019/1
  59. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク|評価対象

    9年間の運用結果*を集計し、主要画面を決定 59 ・2800万アクセス(28M) ・▪チケット表示 + ▪チケット一覧で49% ・利用頻度、遅延 を体感しやすい画面 調査日 2019/1 * 9年分のApache アクセスログに記載されたITSのURI - 2019年1月 33% 16% 7% 4% 4% 4% 4% 3% 3% 3% 2% 2% 2% 1% 1% 11% 2800万アクセス:ベンチマーク対象 チケット表示 チケット一覧 Wikiページ プロジェクトTop (Work_Time) (Redmine_Draft) 検索 添付ダウンロード 添付画像サムネイル ログイン画面 マイページ 時間入力 RedmineTop リポジトリ閲覧 チケットプレビュー その他
  60. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク|評価対象

    9年間の運用結果*を集計し、主要画面を決定 60 ・2800万アクセス(28M) ・▪チケット表示 + ▪チケット一覧で49% ・利用頻度、遅延 を体感しやすい画面 ・ベンチマーク対象が 全体の65.0% を網羅 調査日 2019/1 * 9年分のApache アクセスログに記載されたITSのURI - 2019年1月 33% 16% 7% 4% 4% 4% 3% 3% 2% 2% 2%1% 1% 11% 2800万アクセス:ベンチマーク対象 チケット表示 チケット一覧 Wikiページ プロジェクトTop (Work_Time) (Redmine_Draft) 検索 添付ダウンロード 添付画像サムネイル ログイン画面 マイページ 時間入力 RedmineTop リポジトリ閲覧 チケットプレビュー その他
  61. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク|テストデータ*

    61 規模 0 2 4 6 8 10 12 14 16 0 500 1,000 1,500 2,000 2,500 3,000 10万件 20万件 30万件 50万件 70万件 100万件 150万件 200万件 記 録 文 字 数 億文字 デ ー タ レ コ ー ド 数 万行 チケット数 チケット数 Custom Field(種類) Custom Field(記録) 添付ファイル 時間記録 注記欄 リポジトリ変更 リポジトリ変更セット ウォッチャー Ticket関係性 記録文字数 * 実データ10万チケットを複写して製作 200万チケットは ・3000万レコード ・14億9000万文字 調査日 2019/1 カスタムフィールドは 77種に固定
  62. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク|テストデータ*

    62 200万チケットの内訳 種類 件数 チケット数 200万 カスタムField値 1,200万 添付ファイル 140万 時間記録 74万 注記欄 363万 ウォッチャー数 76万 Ticket間 参照数 27万 記録文字数 14億9,000万 プロジェクト数 113 ユーザー数 457 * 実データ10万チケットを複写して製作 調査日 2019/1
  63. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク|計測方法

    63 Ruby OOBGC * Redmine Ruby 2.0 2016/2/24 EOL Normal 2.6 3.0 3.1 3.2 3.3 3.4 Ruby 2.1 2017/3/31 EOL Normal / OOBGC 2.6 3.0 3.1 3.2 3.3 3.4 Ruby 2.2 2018/3/31 EOL Normal / OOBGC 2.6 3.0 3.1 3.2 3.3 3.4 4.0 Ruby 2.3 2019/3/31 EOL予定 Normal / OOBGC 3.3 3.4 4.0 Ruby 2.4 Normal 3.4 4.0 Ruby 2.5 Normal 4.0 Ruby 2.6 Normal 4.0 組合せ * OOBGC; Out Of Band Garbage Collection。Request処理中にRubyがGCを実行すると応答に遅延が生じる。 指定回数の処理毎に、間隙を縫ってGCを実行させることで応答の遅延を軽減する機能。 Passenger6.0 OS CentOS7 (64bit) Ruby 2.6 Rails5.2 Redmine 4.0 DBMS MySQL 5.7 (BP 8GB) HTTP Apache 2.4 Memory 16GB CPU 4cores VMware ESXi 6.5 【CPU】Intel Xeon Gold 5118 2.3GHz x2 (24Cores/48Threads) , 【Memory】256GB, 【SSD】1.7TB SAS RAID6, 【HDD】12TB 10K RPM SAS RAID6 VCS Subversion1.9 環境構成 SSD/HDD NIC 調査日 2019/1
  64. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク|計測方法

    64 ① 主要画面8種に対して2並列でそれぞれ10回アクセスし、これを5回繰返して計測。 ② 上記①を、下記3種のDBキャッシュ状態を順次切り替えて計測。 (a)DBキャッシュ無 → (b)DBキャッシュ保存・復元 → (c)Fullメモリキャッシュ ③ 上記②の(c)Fullメモリキャッシュの計測値を平均した値を採用。 ④ 上記①~③を、下記要素の全組み合わせ環境で繰り返す。 Redmineバージョン、 Rubyバージョン、OOGBC有無、 10万~200万チケット、SSD/HDD 10万 20万 30万 50万 70万 100万 150万 200万 所要時間合計(ミリ秒) 687.9 691.8 810.4 821.4 833.4 865.4 875.3 884.6 Redmine4.0 Ruby2.5 Passenger6.0 MySQL5.7 BufferPool 8G SSD 主要画面8種のURI /its40 12.5 12.8 12.5 12.5 12.8 12.8 13 12.6 /its40/projects 28.1 28 26.8 27.1 27.2 27.1 27.6 27.1 /its40/projects/sscope 57 56.8 54.1 54.9 54.1 54.6 55.4 53.7 /its40/issues?per_page=200 239 234.3 240.4 239 234.5 232.2 237.7 237.7 /its40/issues/1 83.2 68 181.2 180.5 181.1 180.8 182.2 181.7 /its40/issues/47548 152.9 165.7 169.4 181 198 215.3 231.8 247 /its40/issues/51782 76.6 87.8 87.8 88.3 87.4 87.8 87.9 87.8 /its40/projects/its-issues/wiki 38.6 38.4 38.2 38.1 38.3 38.2 39.7 37.0 調査日 2019/1
  65. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    1000 2000 3000 4000 5000 6000 7000 8000 9000 Ruby2.6 nml jit on Ruby2.2 nml Ruby2.3 nml Ruby2.2 oobgc Ruby2.4 nml Ruby2.3 oobgc Ruby2.6 nml jit off Ruby2.5 nml 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク|計測結果1 65 ms Redmine4.0の最速ベンチ 調査日 2019/1 ※ Experimental
  66. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    1000 2000 3000 4000 5000 6000 7000 8000 9000 Ruby2.6 nml jit on Ruby2.2 nml Ruby2.3 nml Ruby2.2 oobgc Ruby2.4 nml Ruby2.3 oobgc Ruby2.6 nml jit off Ruby2.5 nml 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク|計測結果1 66 ms Redmine4.0の最速ベンチ 調査日 2019/1 ※ Experimental 最も遅い Ruby2.2 に比して、 最も速い Ruby2.5, 2.6 は 21.7% 速い
  67. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    2,000 4,000 6,000 8,000 10,000 12,000 Redmine 2.6 Redmine 3.0 Redmine 3.1 Redmine 3.2 Redmine 3.3 Redmine 3.4 Redmine 4.0 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク|計測結果2 67 ms Redmine4.0は速いのか 調査日 2019/1 ・性能向上(平均) 2.6 → 4.0 29% up 3.0 → 4.0 24% up 3.1 → 4.0 26% up 3.2 → 4.0 29% up 3.3 → 4.0 27% up 3.4 → 4.0 10% up ・原因推測 + Redmine4.0 + Ruby2.5, 2.6 - 機能増加
  68. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    2,000 4,000 6,000 8,000 10,000 12,000 Redmine 2.6 Redmine 3.0 Redmine 3.1 Redmine 3.2 Redmine 3.3 Redmine 3.4 Redmine 4.0 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク|計測結果2 68 ms Redmine4.0は速いのか 調査日 2019/1 ・性能向上(平均) 2.6 → 4.0 29% up 3.0 → 4.0 24% up 3.1 → 4.0 26% up 3.2 → 4.0 29% up 3.3 → 4.0 27% up 3.4 → 4.0 10% up ・原因推測 + Redmine4.0 + Ruby2.5, 2.6 - 機能増加 Redmine2.6/3.2から4.0へアップデートする と、平均で29% の性能向上が得られる
  69. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    2,000 4,000 6,000 8,000 10,000 12,000 Ruby2.6 nml jit on Ruby2.2 nml Ruby2.3 nml Ruby2.2 oobgc Ruby2.4 nml Ruby2.3 oobgc Ruby2.6 nml jit off Ruby2.5 nml 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク|計測結果3 69 Rubyバージョン変更の効果 ms 調査日 2019/1 Redmine4.0 ※ Experimental Ruby2.0 nml Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.1 oobgc Ruby2.4 nml Ruby2.2 oobgc Ruby2.3 oobgc Redmine3.4 Redmine4.0 性能向上(平均) Ruby2.2→2.5/2.6 21.7% Redmine3.4 性能向上(平均) Ruby2.0→2.4 35.4% Ruby2.0→2.3OOBGC 37.4%
  70. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    2,000 4,000 6,000 8,000 10,000 12,000 Ruby2.6 nml jit on Ruby2.2 nml Ruby2.3 nml Ruby2.2 oobgc Ruby2.4 nml Ruby2.3 oobgc Ruby2.6 nml jit off Ruby2.5 nml 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク|計測結果3 70 Rubyバージョン変更の効果 調査日 2019/1 Redmine4.0 ※ Experimental Ruby2.0 nml Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.1 oobgc Ruby2.4 nml Ruby2.2 oobgc Ruby2.3 oobgc Redmine3.4 Redmine4.0 性能向上(平均) Ruby2.2→2.5 21.7% Redmine3.4 性能向上(平均) Ruby2.0→2.4 37.4% Ruby2.0→2.3OOBGC 36.7% ※ Experimental Redmine4.0において、Ruby2.2から2.5/2.6へ Updateすると平均21.7% の性能向上が得られる ms
  71. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    2,000 4,000 6,000 8,000 10,000 12,000 Ruby2.0 nml Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.1 oobgc Ruby2.4 nml Ruby2.2 oobgc Ruby2.3 oobgc ベンチマーク|計測結果3 71 OOBGCの効果 71 調査日 2019/1 Redmine3.4 Redmine3.4 性能向上(平均) OOBGC効果 Ruby2.3→2.3OOBGC 7.3% up ms
  72. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    2,000 4,000 6,000 8,000 10,000 12,000 Ruby2.0 nml Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.1 oobgc Ruby2.4 nml Ruby2.2 oobgc Ruby2.3 oobgc ベンチマーク|計測結果3 72 OOBGCの効果 72 調査日 2019/1 Redmine3.4 Redmine3.4 性能向上(平均) OOBGC効果 Ruby2.3→2.3OOBGC 7.3% up ms Redmine3.4において、Ruby2.3にOOBGCを適用すると 平均 7.3% の性能向上が得られる Redmine4.0, Ruby2.4/2.5/2.6 のOOBGCは動作せず調査はできなかった。
  73. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク|計測結果4

    73 過去のRedmineと比較 Redmineは速くなった? 遅くなった? 調査日 2019/1
  74. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    1000 2000 3000 4000 5000 6000 7000 8000 9000 Redmine1.4 最 速 Redmine2.0 最 速 Redmine2.1 最 速 Redmine2.3 最 速 Redmine2.6 最 速 Redmine3.0 最 速 Redmine3.1 最 速 Redmine3.2 最 速 Redmine3.3 最 速 Redmine3.4 最 速 Redmine4.0 最 速 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク|計測結果4 74 過去のRedmineと比較 調査日 2019/1 最速ベンチマークを 比較すると、 2.3 → 2.6 – 26.4% 性能が低下している ms
  75. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    1000 2000 3000 4000 5000 6000 7000 8000 9000 Redmine1.4 最 速 Redmine2.0 最 速 Redmine2.1 最 速 Redmine2.3 最 速 Redmine2.6 最 速 Redmine3.0 最 速 Redmine3.1 最 速 Redmine3.2 最 速 Redmine3.3 最 速 Redmine3.4 最 速 Redmine4.0 最 速 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク|計測結果4 75 過去のRedmineと比較 調査日 2019/1 最速ベンチマークを 比較すると、 2.3 → 2.6 – 26.4% 2.3 → 3.4 – 13.5% 2.3 → 4.0 – 5.3% 性能が低下している ms
  76. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    1000 2000 3000 4000 5000 6000 7000 8000 9000 Redmine1.4 最 速 Redmine2.0 最 速 Redmine2.1 最 速 Redmine2.3 最 速 Redmine2.6 最 速 Redmine3.0 最 速 Redmine3.1 最 速 Redmine3.2 最 速 Redmine3.3 最 速 Redmine3.4 最 速 Redmine4.0 最 速 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク|計測結果4 76 過去のRedmineと比較 調査日 2019/1 ms 性能変化の原因推測 + Redmine内部改善 + Ruby高速化 + Multi Thread対応 + Rails5の内部改善 - 機能増加 ※ Redmine2.3以前の計測は当時の 計算機とRuby1.8, 1.9, 2.0による もの。現在は電算機の能力が向上し ており比較精度は完全でない。よっ て参考値とする。
  77. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    1000 2000 3000 4000 5000 6000 7000 8000 9000 Redmine1.4 最 速 Redmine2.0 最 速 Redmine2.1 最 速 Redmine2.3 最 速 Redmine2.6 最 速 Redmine3.0 最 速 Redmine3.1 最 速 Redmine3.2 最 速 Redmine3.3 最 速 Redmine3.4 最 速 Redmine4.0 最 速 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク|計測結果4 77 過去のRedmineと比較 調査日 2019/1 ms 機能増加 Redmine 2.3, 2.4, 2.5, 2.6, 3.0, 3.1,3.2, 3.3, 3.4, 4.0 Spent time 2013-03~2018-12 (5y9m) Includes 374 Features implemented 641 Patches applied 673 Defects fixed Getting faster and remarkably reliable!
  78. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    1000 2000 3000 4000 5000 6000 7000 8000 9000 Redmine1.4 最 速 Redmine2.0 最 速 Redmine2.1 最 速 Redmine2.3 最 速 Redmine2.6 最 速 Redmine3.0 最 速 Redmine3.1 最 速 Redmine3.2 最 速 Redmine3.3 最 速 Redmine3.4 最 速 Redmine4.0 最 速 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク|計測結果4 78 過去のRedmineと比較 調査日 2019/1 ms 機能増加 Redmine 2.3, 2.4, 2.5, 2.6, 3.0, 3.1,3.2, 3.3, 3.4, 4.0 Spent time 2013-03~2018-12 (5y9m) Includes 374 Features implemented 641 Patches applied 673 Defects fixed Getting faster and remarkably reliable! ・Redmine2.3を4.0へUpdateすると5.3% 性能が 低下する ・数多くの有益な機能が追加されたのにも関わらず コア開発チームの努力と技術の進歩により、 応答性能の低下は最小限にとどめられた
  79. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク|小まとめ(1/2)

    79 Redmine4.0の性能が改善した主な理由 理由1:Ruby2.5, 2.6の処理性能向上 Issue# Subject Ruby2.5 #14104 命令列中のすべての trace 命令を削除することで、5~10% の高速化 #14045 Lazy Proc allocation #13517 Mutex がよりコンパクトかつ高速に書き直された - ERB は Ruby 2.4 に比べて 2 倍の速度でテンプレートからコードを生成するよ うになった - 組み込みメソッドの速度が向上(Array#concat、Enumerable#sort_by、 String#concat、String#index、Time#+) #13867 IO.copy_streamがcopy_file_range(2)を使ってコピーのオフロードを試みるよ うになった Ruby2.6 #14318 Proc#callが高速化された #14330 渡されたブロックの呼び出し block.call が高速化された #14989 Transient Heap (theap) が導入された #14739 コルーチンをネイティブ実装による、Fiberのコンテキスト切り替えの性能が大 幅に向上した 調査日 2019/1
  80. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク|小まとめ(2/2)

    80 Redmine4.0の性能が改善した主な理由 理由2:Redmine core パフォーマンス改善10種 Issue# Subject 30465 Deadlock when assigning custom values 29406 Use sorted instead of sort 29363 Use String#tr instead of String#gsub 29359 Switch to mini_mime from mime-types 29305 Use Hash#each_key instead of Hash#keys.each 29299 Use Enumerable#sort_by instead of Enumerable#sort 28952 Update User#last_login_on only once per minute 27671 Use reverse_each instead of reverse.each for better performance 26747 Use find_by instead of where.first to remove unnecessary sorting 26711 Use pluck instead of collect/map 30465 Deadlock when assigning custom values 調査日 2019/1
  81. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク|計測結果5

    81 今回のベンチマークはSSDで行った。 HDDとSSDの性能差はどの程度か?
  82. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    2,000 4,000 6,000 8,000 10,000 12,000 NO Cache Redmine4.0 HDD NO Cache Redmine4.0 SSD FULL Cache Redmine4.0 HDD FULL Cache Redmine4.0 SSD 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク|計測結果5 82 HDDをSSDに置換する効果 調査日 2019/1 ms Redmine4.0 HDD→ SSDの性能向上 No Cache 28.5% avg Disk I/Oに依存する処理が大半を占めた時 例)起動直後、キャッシュ未設定、メモリ不足、 大量データなどの理由により、処理対象データを Diskから読込むため時間がかかる Full Cached 3.6% avg キャッシュシステムによってDisk I/Oが不 要、または減少した処理が大半を占めた時 例)処理対象データは既に読み込まれてメモリ上に プールされており、すぐに取り出せる
  83. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    2,000 4,000 6,000 8,000 10,000 12,000 NO Cache Redmine4.0 HDD NO Cache Redmine4.0 SSD FULL Cache Redmine4.0 HDD FULL Cache Redmine4.0 SSD 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク|計測結果5 83 HDDをSSDに置換する効果 調査日 2019/1 ms Redmine4.0 HDD→ SSDの性能向上 No Cache 28.5% avg Disk I/Oに依存する処理が大半を占めた時 例)起動直後、キャッシュ未設定、メモリ不足、 大量データなどの理由により、処理対象データを Diskから読込むため時間がかかる Full Cached 3.6% avg キャッシュシステムによってDisk I/Oが不 要、または減少した処理が大半を占めた時 例)処理対象データは既に読み込まれてメモリ上に プールされており、すぐに取り出せる HDDをSSDに交換すると、 平均28.5% の性能向上が得られる
  84. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク|計測結果6

    84 複数プラグイン導入の性能への影響 Redmineの性能に、プラグインがどの程度 の影響を与えるのか?
  85. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク|計測結果6

    85 複数プラグイン導入の性能への影響 Redmine Pluginの多くはHook によって各処理に割り込みをか けている。性能が十分に考慮さ れていないコードが呼び出され た場合、応答性能に影響する。 選出した16種のうち8種は Redmine3.0に未対応だった。 プラグインを追加して応答時間 を計測した結果、平均4%の性能 低下が計測された。 0 2000 4000 6000 8000 10000 12000 Redmine3.0 Redmine3.0 - With Plugins 10万 20万 30万 50万 70万 100万 150万 200万 ms 調査日 2015/5
  86. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク|計測結果6

    86 複数プラグイン導入の性能への影響 0 2000 4000 6000 8000 10000 12000 Redmine3.0 Redmine3.0 - With Plugins 10万 20万 30万 50万 70万 100万 150万 200万 ms Redmine Pluginの多くはHook によって各処理に割り込みをか けている。性能が十分に考慮さ れていないコードが呼び出され た場合、応答性能に影響する。 選出した16種のうち8種は Redmine3.0に未対応だった。 プラグインを追加して応答時間 を計測した結果、平均4%の性能 低下が計測された。 不要なPluginを除去することで、 応答性能が平均4% 向上するケースがある 調査日 2015/5
  87. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク|計測結果7

    87 FTS* 応答性能の計測 1. Redmine4.0の全文検索性能 2. Full Text Searchプラグインの導入による 高速化の程度 3. 35万添付ファイルの内容検索の性能 * FTS; Full Text Search 全文検索(索引型/非索引型)
  88. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 88

    Redmine Ruby OOBGC * MySQL FTS Plugin 3.0 Ruby 2.2 2018/3/31 EOL OOBGC 5.7 - 4.0 Ruby 2.5 (2.6) Normal 5.7 ON / OFF 組合せ * OOBGC; Out Of Band Garbage Collection。Request処理中にRubyがGCを実行すると応答に遅延が生じる。 指定回数の処理毎に、間隙を縫ってGCを実行させることで応答の遅延を軽減する機能。 Passenger6.0 OS CentOS7 (64bit) Ruby 2.5 (2.6) Rails5.2 Redmine 4.0 DBMS MySQL 5.7 (BP 8GB) HTTP Apache 2.4 Memory 16GB CPU 4cores VMware ESXi 6.5 【CPU】Intel Xeon E5-2670 2.3GHz x2 (24Cores/48Threads) , 【Memory】256GB, 【SSD】8.7TB SAS RAID6, 【HDD】6TB 10K RPM SAS RAID6 VCS Subversion1.9 環境構成 SSD/HDD NIC 調査日 2019/1 FTS* 応答性能の計測 ベンチマーク|計測結果7
  89. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 89

    ① 検索キーワード3種に対して2並列でそれぞれ2回アクセスして計測値を平均。3種を 合算して所要時間合計とする ② 上記①を、下記3種のキャッシュ状態を順次切り替えて計測 全キャッシュ無 → Fullメモリキャッシュ ③ 上記②の全キャッシュ無、Fullメモリキャッシュの計測値を採用 ④ 上記①~③を、下記要素の全組み合わせ環境で繰り返す Redmineバージョン、 Rubyバージョン、OOGBC有無、 MySQLバージョン、10万~200万チケット、SSD固定 10万 20万 30万 50万 70万 100万 150万 200万 所要時間合計(ミリ秒) 1735.4 2286.9 2880.4 3983.7 5135.6 6836.7 9841.8 12340.2 Redmine4.0 Ruby2.5 MySQL5.7 BufferPool 8G SSD Plug-in ON No Cache 検索キーワード3種のURI /its40/search?q=ATO 1181.8 1337.1 1534.2 1904.0 2283.7 2864.4 3852.1 4732.5 /its40/search?q=WIP 279.7 477.3 674.0 1034.8 1425.0 1970.3 2966.9 3778.9 /its40/search?q=sSCOPE 273.9 472.5 672.2 1044.9 1426.9 2002.0 3022.8 3828.8 調査日 2019/1 FTS* 応答性能の計測 ベンチマーク|計測結果7 * FTS; Full Text Search 全文検索(索引型/非索引型)
  90. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    200 400 600 800 1,000 1,200 No Cash Full Cash No Cash Full Cash No Cash Full Cash Redmine3.0 非索引型 Redmine4.0 非索引型 Redmine4.0 索引型 全 文 検 索 所 用 時 間 平 均 積 算 ( 秒 ) 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク|計測結果7 90 FTS* 応答性能の計測 秒 調査日 2019/1 * FTS; Full Text Search 全文検索(索引型/非索引型) Redmineの全文検索処理 ・非索引型 ・索引型(プラグイン導入) Redmine Full Text Search V0.7.3+ OSS検索エンジン Goonga 計測時のキャッシュ状態2種 ・No Cash ・Full Cashed 計測対象 1) /its40/search?q=ATO 2) /its40/search?q=WIP 3) /its40/search?q=sSCOPE Redmine4.0 非索引型 索引型 Redmine4.0 非索引型 Redmine3.0
  91. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    200 400 600 800 1,000 1,200 No Cash Full Cash No Cash Full Cash No Cash Full Cash Redmine3.0 非索引型 Redmine4.0 非索引型 Redmine4.0 索引型 全 文 検 索 所 用 時 間 平 均 積 算 ( 秒 ) 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク|計測結果7 91 FTS* 応答性能の計測 秒 調査日 2019/1 * FTS; Full Text Search 全文検索(索引型/非索引型) Redmine3.0 Redmine4.0 非索引型 索引型 Redmine4.0 非索引型 Redmine3.0 非索引型 全文検索 チケット数 No Cache Full Cache 10万 15.3 0.6 20万 29.5 1.0 30万 46.5 1.4 50万 78.1 2.4 70万 108.8 3.5 100万 165.7 4.9 150万 253.6 7.3 200万 355.3 9.7 合計 1052.8 30.8 計測値単位: 秒(sec)
  92. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    200 400 600 800 1,000 1,200 No Cash Full Cash No Cash Full Cash No Cash Full Cash Redmine3.0 非索引型 Redmine4.0 非索引型 Redmine4.0 索引型 全 文 検 索 所 用 時 間 平 均 積 算 ( 秒 ) 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク|計測結果7 92 FTS* 応答性能の計測 秒 調査日 2019/1 * FTS; Full Text Search 全文検索(索引型/非索引型) Redmine3.0 Redmine4.0 非索引型 索引型 Redmine4.0 非索引型 Redmine3.0 非索引型 全文検索 チケット数 No Cache Full Cache 10万 15.3 0.6 20万 29.5 1.0 30万 46.5 1.4 50万 78.1 2.4 70万 108.8 3.5 100万 165.7 4.9 150万 253.6 7.3 200万 355.3 9.7 合計 1052.8 30.8 計測値単位: 秒(sec) ・Redmine3.0 非索引型は10万チケットの初回検索が平均15.3秒 ・データをメモリ上へ読み込むにつれてFull Cacheの速度に近づく ・日常の検索は全横断ではなくプロジェクト内なので速い
  93. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    200 400 600 800 1,000 1,200 No Cash Full Cash No Cash Full Cash No Cash Full Cash Redmine3.0 非索引型 Redmine4.0 非索引型 Redmine4.0 索引型 全 文 検 索 所 用 時 間 平 均 積 算 ( 秒 ) 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク|計測結果7 93 FTS* 応答性能の計測 秒 調査日 2019/1 * FTS; Full Text Search 全文検索(索引型/非索引型) Redmine3.0 Redmine4.0 非索引型 索引型 Redmine4.0 非索引型 Redmine4.0 非索引型 全文検索 チケット数 No Cache Full Cache 10万 4.7 0.5 20万 7.9 0.9 30万 11.6 1.2 50万 21.0 2.0 70万 28.4 2.9 100万 40.5 4.2 150万 61.7 6.5 200万 82.5 8.5 合計 258.3 26.7 計測値単位: 秒(sec)
  94. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    200 400 600 800 1,000 1,200 No Cash Full Cash No Cash Full Cash No Cash Full Cash Redmine3.0 非索引型 Redmine4.0 非索引型 Redmine4.0 索引型 全 文 検 索 所 用 時 間 平 均 積 算 ( 秒 ) 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク|計測結果7 94 FTS* 応答性能の計測 秒 調査日 2019/1 * FTS; Full Text Search 全文検索(索引型/非索引型) Redmine3.0 Redmine4.0 非索引型 索引型 Redmine4.0 非索引型 Redmine4.0 非索引型 全文検索 チケット数 No Cache Full Cache 10万 4.7 0.5 20万 7.9 0.9 30万 11.6 1.2 50万 21.0 2.0 70万 28.4 2.9 100万 40.5 4.2 150万 61.7 6.5 200万 82.5 8.5 合計 258.3 26.7 計測値単位: 秒(sec) ・Redmine4.0 非索引型は10万チケットの初回検索が平均4.7秒 ・データをメモリ上へ読み込むにつれてFull Cacheの速度に近づく ・日常の検索は全横断ではなくプロジェクト内なので十分に速い
  95. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    200 400 600 800 1,000 1,200 No Cash Full Cash No Cash Full Cash No Cash Full Cash Redmine3.0 非索引型 Redmine4.0 非索引型 Redmine4.0 索引型 全 文 検 索 所 用 時 間 平 均 積 算 ( 秒 ) 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク|計測結果7 95 FTS* 応答性能の計測 秒 調査日 2019/1 * FTS; Full Text Search 全文検索(索引型/非索引型) Redmine3.0 Redmine4.0 非索引型 索引型 Redmine4.0 非索引型 Redmine4.0 索引型 全文検索 チケット数 No Cache Full Cache 10万 1.7 0.1 20万 2.3 0.1 30万 2.9 0.1 50万 4.0 0.1 70万 5.1 0.1 100万 6.8 0.1 150万 9.8 0.1 200万 12.3 0.1 合計 44.9 0.8 計測値単位: 秒(sec)
  96. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    200 400 600 800 1,000 1,200 No Cash Full Cash No Cash Full Cash No Cash Full Cash Redmine3.0 非索引型 Redmine4.0 非索引型 Redmine4.0 索引型 全 文 検 索 所 用 時 間 平 均 積 算 ( 秒 ) 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク|計測結果7 96 FTS* 応答性能の計測 秒 調査日 2019/1 * FTS; Full Text Search 全文検索(索引型/非索引型) Redmine3.0 Redmine4.0 非索引型 索引型 Redmine4.0 非索引型 Redmine4.0 索引型 全文検索 チケット数 No Cache Full Cache 10万 1.7 0.1 20万 2.3 0.1 30万 2.9 0.1 50万 4.0 0.1 70万 5.1 0.1 100万 6.8 0.1 150万 9.8 0.1 200万 12.3 0.1 合計 44.9 0.8 計測値単位: 秒(sec) ・Redmine4.0 索引型は10万チケットの初回検索が平均1.7秒 ・索引データを一度メモリに読み込むとFull Cacheの速度になり、 データが増加しても0.1秒を維持 ・200万チケット(約15億文字)の索引データサイズは約9GB メモリを追加して起動時に読み込めばFull Cashスピードになる
  97. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク|計測結果7

    97 FTS 応答性能の計測 調査日 2019/1 * 表中の数値は検索キーワード3種の所要時間の合計 10万 0.1M 20万 0.2M 30万 0.3M 50万 0.5M 70万 0.7M 100万 1M 150万 1.5M 200万 2M 平均 AVG Redmine 3.0 非索引型 No Index No Cash 15.3 29.5 46.5 78.1 108.8 165.7 253.6 355.3 131.6 Full Cash 0.6 1.0 1.4 2.4 3.5 4.9 7.3 9.7 3.8 Redmine 4.0 非索引型 No Index No Cash 4.7 7.9 11.6 21.0 28.4 40.5 61.7 82.5 32.3 Full Cash 0.5 0.9 1.2 2.0 2.9 4.2 6.5 8.5 3.3 Redmine 4.0 索引型 FTS Indices No Cash 1.7 2.3 2.9 4.0 5.1 6.8 9.8 12.3 5.6 Full Cash 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 全文検索 所用時間(秒 sec)*
  98. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク|計測結果7

    98 FTS 応答性能の計測 調査日 2019/1 10万 0.1M 20万 0.2M 30万 0.3M 50万 0.5M 70万 0.7M 100万 1M 150万 1.5M 200万 2M 平均 AVG Redmine 3.0 非索引型 No Index No Cash 15.3 29.5 46.5 78.1 108.8 165.7 253.6 355.3 131.6 Full Cash 0.6 1.0 1.4 2.4 3.5 4.9 7.3 9.7 3.8 Redmine 4.0 非索引型 No Index No Cash 4.7 7.9 11.6 21.0 28.4 40.5 61.7 82.5 32.3 Full Cash 0.5 0.9 1.2 2.0 2.9 4.2 6.5 8.5 3.3 Redmine 4.0 索引型 FTS Indices No Cash 1.7 2.3 2.9 4.0 5.1 6.8 9.8 12.3 5.6 Full Cash 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 全文検索 所用時間(秒 sec)* ・Redmine3.0の全文検索(非索引型)は10万チケットで、 * 表中の数値は検索キーワード3種の所要時間の合計
  99. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク|計測結果7

    99 FTS 応答性能の計測 調査日 2019/1 10万 0.1M 20万 0.2M 30万 0.3M 50万 0.5M 70万 0.7M 100万 1M 150万 1.5M 200万 2M 平均 AVG Redmine 3.0 非索引型 No Index No Cash 15.3 29.5 46.5 78.1 108.8 165.7 253.6 355.3 131.6 Full Cash 0.6 1.0 1.4 2.4 3.5 4.9 7.3 9.7 3.8 Redmine 4.0 非索引型 No Index No Cash 4.7 7.9 11.6 21.0 28.4 40.5 61.7 82.5 32.3 Full Cash 0.5 0.9 1.2 2.0 2.9 4.2 6.5 8.5 3.3 Redmine 4.0 索引型 FTS Indices No Cash 1.7 2.3 2.9 4.0 5.1 6.8 9.8 12.3 5.6 Full Cash 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 全文検索 所用時間(秒 sec)* ・Redmine3.0の全文検索(非索引型)は10万チケットで、 4.0は20~30万チケットで実用性能の限界に到達する。 * 表中の数値は検索キーワード3種の所要時間の合計
  100. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク|計測結果7

    100 FTS 応答性能の計測 調査日 2019/1 10万 0.1M 20万 0.2M 30万 0.3M 50万 0.5M 70万 0.7M 100万 1M 150万 1.5M 200万 2M 平均 AVG Redmine 3.0 非索引型 No Index No Cash 15.3 29.5 46.5 78.1 108.8 165.7 253.6 355.3 131.6 Full Cash 0.6 1.0 1.4 2.4 3.5 4.9 7.3 9.7 3.8 Redmine 4.0 非索引型 No Index No Cash 4.7 7.9 11.6 21.0 28.4 40.5 61.7 82.5 32.3 Full Cash 0.5 0.9 1.2 2.0 2.9 4.2 6.5 8.5 3.3 Redmine 4.0 索引型 FTS Indices No Cash 1.7 2.3 2.9 4.0 5.1 6.8 9.8 12.3 5.6 Full Cash 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 全文検索 所用時間(秒 sec)* ・Redmine3.0の全文検索(非索引型)は10万チケットで、 4.0は20~30万チケットで実用性能の限界に到達する。 ・Redmine4.0に索引型の全文検索Pluginを導入すると、 実用的な検索速度は3.0に比べて平均で23倍速くなる。 * 表中の数値は検索キーワード3種の所要時間の合計
  101. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 10万

    0.1M 20万 0.2M 30万 0.3M 50万 0.5M 70万 0.7M 100万 1M 150万 1.5M 200万 2M 平均 AVG Redmine 3.0 非索引型 No Index No Cash 15.3 29.5 46.5 78.1 108.8 165.7 253.6 355.3 131.6 Full Cash 0.6 1.0 1.4 2.4 3.5 4.9 7.3 9.7 3.8 Redmine 4.0 非索引型 No Index No Cash 4.7 7.9 11.6 21.0 28.4 40.5 61.7 82.5 32.3 Full Cash 0.5 0.9 1.2 2.0 2.9 4.2 6.5 8.5 3.3 Redmine 4.0 索引型 FTS Indices No Cash 1.7 2.3 2.9 4.0 5.1 6.8 9.8 12.3 5.6 Full Cash 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 0.1 ベンチマーク|計測結果7 101 FTS 応答性能の計測 調査日 2019/1 全文検索 所用時間(秒 sec)* ・Redmine3.0の全文検索(非索引型)は10万チケットで、 4.0は20~30万チケットで実用性能の限界に到達する。 ・Redmine4.0に索引型の全文検索Pluginを導入すると、 実用的な検索速度は3.0に比べて平均で23倍速くなる。 ・200万チケット(≒15億文字)を1件あたり* 平均1.9秒で検索可能になる。 2 million tickets include approximately 1.5 billion multi-byte characters. Indexed FTS takes 1.9s (Avg per 1 search). * 表中の数値は検索キーワード3種の所要時間の合計
  102. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク|計測結果8

    102 FTS 応答性能の計測 調査日 2019/X 35万添付ファイルを検索対象としたときの全文検索の性能計測 1)実運用環境の35万ファイルを使用して、全文検索(非索引型)の応答性能を計測し た。今回は約30億文字でスタートするが、将来データが増加した状態を最大200億文 字と想定すると、検索時間が長時間化して使い物にならない可能性がある。 2)検索結果の精度も問題となる。現状のSQLによる検索では、探したい情報が大量 のデータに埋もれてしまい使い物にならない可能性がある。 1ファイルの平均文字数:3000文字(想定) 添付 1ファイル 平均3000文字 (オフィス文書、集計表、論文) リポジトリ 1ファイル 平均3000文字 (ソース、設計文書) 試算 10万ファイル= 3億文字 200万ファイル= 60億文字 500万ファイル=150億文字 1000万ファイル=300億文字 データ計測中 グラフ作成予定
  103. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク|計測結果8

    103 FTS 応答性能の計測 調査日 2019/X 35万ファイルのデータ量は 約10億文字 1ファイル平均3000文字 ・オフィス文書 ・集計表 ・論文 35万添付ファイルを検索対象としたときの全文検索の性能計測 データ計測中 グラフ作成予定 友情出演:ぬるくま 様
  104. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク|計測結果9

    104 Redmine4.0は200万チケットでも “サクサク”なのか?
  105. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    100 200 300 400 500 600 700 800 900 1000 10万 20万 30万 50万 70万 100万 150万 200万 Wiki Top チケット表示(小) チケット表示(大) チケット表示(中) チケット一覧 プロジェクトTop プロジェクト一覧 Redmine Top ベンチマーク|計測結果9 105 Redmine4.0は200万チケットでも “サクサク”なのか? ms 調査日 2019/1
  106. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    100 200 300 400 500 600 700 800 900 1000 10万 20万 30万 50万 70万 100万 150万 200万 Wiki Top チケット表示(小) チケット表示(大) チケット表示(中) チケット一覧 プロジェクトTop プロジェクト一覧 Redmine Top ベンチマーク|計測結果9 106 Redmine4.0は200万チケットでも “サクサク”なのか? ms 調査日 2019/1
  107. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    100 200 300 400 500 600 700 800 900 1000 10万 20万 30万 50万 70万 100万 150万 200万 Wiki Top チケット表示(小) チケット表示(大) チケット表示(中) チケット一覧 プロジェクトTop プロジェクト一覧 Redmine Top ベンチマーク|計測結果9 107 Redmine4.0は200万チケットでも “サクサク”なのか? ms 調査日 2019/1 チューニングの結果、Redmine4.0の 主要画面8種の平均応答時間は103ms
  108. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    100 200 300 400 500 600 700 800 900 1000 10万 20万 30万 50万 70万 100万 150万 200万 Wiki Top チケット表示(小) チケット表示(大) チケット表示(中) チケット一覧 プロジェクトTop プロジェクト一覧 Redmine Top ベンチマーク|計測結果9 108 Redmine4.0は200万チケットでも “サクサク”なのか? ms 調査日 2019/1 ①全文検索 20秒 Full_Text_Search Plugin ②DB始動時の暖機運転5分 MySQL5.6, Postgres9.4に対策有り (BufferPool dump/Restore) ③BufferPool 8GB以上必須 ④SSD
  109. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0

    100 200 300 400 500 600 700 800 900 1000 10万 20万 30万 50万 70万 100万 150万 200万 Wiki Top チケット表示(小) チケット表示(大) チケット表示(中) チケット一覧 プロジェクトTop プロジェクト一覧 Redmine Top ③BufferPool 8GB以上必須 ④SSD ベンチマーク|計測結果9 109 Redmine4.0は200万チケットでも “サクサク”なのか? ms 調査日 2019/1 ①全文検索 20秒 Full_Text_Search Plugin ②DB始動時の暖機運転5分 MySQL5.6, Postgres9.4に対策有り (BufferPool dump/Restore) 4点対策して環境を整備すれば 200万チケットまで大丈夫
  110. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次

    110 第1部 背景と要求 第2部 チューニングの基本 第3部 ベンチマーク 第4部 全文検索機能の拡張 第5部 性能改善事例集 第6部 まとめ 110
  111. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 全文検索機能の拡張

    111 【要求】 ・添付ファイルとリポジトリの内容を高速に検索したい ・大量のデータが収容されるので検索精度を向上したい 【想定】 ・10年後の想定 = 200億文字 200万チケット= 30億文字(1500文字/1チケット換算) Wiki, コメント= 20億文字 500万ファイル= 150億文字 (平均3000文字/ファイル、添付ファイル200万、リポジトリ300万) 【機能拡張】 1. 添付ファイルとリポジトリ検索機能 2. 200億文字の全文検索を300ms以内に実現 3. 高精度検索(機械学習によるAI検索) 【OSS開発】 ・株式会社クリアコードさんと株式会社島津製作所の共同開発 ・開発成果物はオープンソースとして公開
  112. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 全文検索機能の拡張

    112 検索対象 50億文字 ・添付ファイル35万 10億文字 ・リポジトリ100万ファイル 40億文字 1ファイル平均3000文字 ・オフィス文書 ・集計表 ・論文 ・ソースコード ・製品ドキュメント 添付ファイルとSubversionリポジトリを検索対象としたときの全文検索の性能計測 開発中 データ計測予定 (画餅) 友情出演:京都 出町ふたば の まめ餅 様
  113. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次

    113 第1部 背景と要求 第2部 チューニングの基本 第3部 ベンチマーク 第4部 全文検索機能の拡張 第5部 性能改善事例集 第6部 まとめ 113
  114. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 性能改善事例集

    114 1. 9年間に渡るRedmineの運用におい て、どのような問題が発生し、どう やって解消したのか 2. 信頼性と安定性を維持する取組みの 「実際と限界」に焦点 3. 各種設定、チューニング方法、性能計 測方法を全て紹介する
  115. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 計測

    - 定量化手法 「測定できないものは制御できない」* 115 * DeMarco, Tom., 1982, “You can’t control what you can't measure.”
  116. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 計測

    - 定量化手法 「測定できないものは制御できない」* 1.テスト実行時間 (Redmine Built-in Test Code) 2.負荷ベンチマーク ・httpref https://github.com/httperf/httperf ・wrk https://github.com/wg/wrk ・apache bench http://httpd.apache.org/docs/2.4/programs/ab.html 3.時間計測 ・MySQL Slow-query ログ ・Redmineログ (Production.log, Development.log) 4.分析 ・SQL実行計画(MySQL Workbench) https://www-jp.mysql.com/products/workbench/ ・Chrome開発者ツール https://developers.google.com/web/tools/chrome-devtools/ ・ネットワークスループット調査 iperf https://iperf.fr/ (Win版は× : ブルースクリーン死亡) 116 * DeMarco, Tom., 1982, “You can’t control what you can't measure.”
  117. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングチェックリスト20

    1/2 117 1)Memory搭載・設定 DBMSに十分なキャッシュメモリを付与 2)Disk I/O HDD→ SSD 3)CPUコア数と同時並行処理数 4)OS選択 Linux / 起動プロセスとパッケージは必要最低限に削ぎ落とす。 5)DBMS選択 MySQL, Postgresql を使用して、必ず設定値を変更。 6)通信データ圧縮 Apache等 HTTP/1.1 Compression 7)Rubyバージョン利用可能な最新版を使用 1.9 < 2.0 < < < 2.1 < 2.2 < 2.3 < 2.4 < 2.5 ≒ 2.6 8)Webアプリケーションサーバー選択 WEBrick < < < Thin < < Passenger5 / 6 9)通信経路の狭帯域対策 10M/bps → 1G/bps (ケーブル交換、装置交換) 同一サーバーに置くことで通信帯域を広くする。Local Loopback は最速のNIC 10)通信装置の性能向上 Normal-HubをSwitching-Hubへ交換しコリジョンによる通信効率低下を回避 11)Subversionリポジトリの同期トリガを変更
  118. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 118

    12)Subversionリポジトリの同期対象を指定する 13)Subversionセッションキャッシュを付与する 14)Subversion通信圧縮機能を利用する 15)MySQLメモリチューニング メモリを十分に付与し、全インデックスや全データをできるだけオンメモリ化 16)カスタムフィールドの設定 「検索対象」の数が多いと極端に性能が落ちる 17)DBMSサーバーの「暖機運転」 MySQL 5.6以降: Buffer-Pool Save & Load PostgreSQL 9.4以降: pg_prewarm 18)メール非同期送信(Async) 19)Plugin導入数 20)RubyとGC ・内部処理の大幅改善によりRuby2.5が最速のバージョン( 調査時点 2019/1 ) ・2位は Ruby2.3+OOBGC チューニングチェックリスト20 2/2
  119. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例1)【性能】全体がひどく遅い

    119 【チューニング要素】 ・H/W: HDD, Memory, CPU ・S/W: OS, DBMS, Http Server, Ruby, WebAppServer ・N/W: 通信帯域, Switching-Hub
  120. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例1)【性能】全体がひどく遅い

    120 【チューニング要素】 ・H/W: HDD, Memory, CPU ・S/W: OS, DBMS, Http Server, Ruby, WebAppServer ・N/W: 通信帯域, Switching-Hub 1)Memory搭載・設定 DBMSに十分なキャッシュメモリを付与 2)Disk I/O HDD→ SSD OS, DBMS, APL(Redmine他)はSSDに格納し、他のデータはHDDへ 3)CPUコア数と同時並行処理数 処理要求が集中した時の待ち行列 CPUコアやHTスレッド数に合わせて並行度を上げ、最大待ち時間を低く抑える。 - Passenger:自動調整 (指定可能) - Unicorn , Thin:起動サーバー数を増減
  121. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例1)【性能】全体がひどく遅い

    121 【チューニング要素】 ・H/W: HDD, Memory, CPU ・S/W: OS, DBMS, Http Server, Ruby, WebAppServer ・N/W: 通信帯域, Switching-Hub 4)OS選択 Windows Bitnamiは10万件まで(制約:Ruby2.3系, DBMS 32bit) 最新のBitnami 3.4, 4.0系はRuby2.3に。未調査だが期待。(制約:DBMS 32bit) 15万件以上扱うなら、Windows上にスクラッチでRedmine構築を推奨 20万件以上扱うなら200万件まで確認したLinux 64bitを推奨 5)DBMS選択 MySQL, Postgresql を使用して, 必ず設定値を変更。Sqliteは1万チケットまで 6)通信データ圧縮 Apache等 HTTP/1.1 Compression ネットワーク帯域が狭い時、通信輻輳時に高い効果
  122. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例1)【性能】全体がひどく遅い

    122 【チューニング要素】 ・H/W: HDD, Memory, CPU ・S/W: OS, DBMS, Http Server, Ruby, WebAppServer ・N/W: 通信帯域, Switching-Hub 7)Rubyバージョン 利用可能な最新版を使用 1.9 < 2.0 < < < 2.1 < 2.2 < 2.3 < 2.4 < 2.5 ≒ 2.6 8)Webアプリケーションサーバー選択 WEBrick < < < Thin < < Passenger6 (Unicornは未調査。速いがPassengerに比して扱い難い。上級者向け) 9)通信経路の狭帯域対策 10M/bps → 1G/bps (ケーブル+Switch機器を交換) Local Loopback は最速のNIC 10)通信装置の性能向上 Normal-HubをSwitchへ交換しコリジョンによる通信効率低下を回避
  123. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例2)【性能】リポジトリタブが遅い

    123 【チューニング要素】 ・H/W: HDD, Memory, CPU ・S/W: DBMS, Ruby, WebAppServer, Subversion Server ・N/W: 通信帯域, Switching-Hub 1)Subversionリポジトリの同期トリガを変更 SubversionとRedmine間のリポジトリ同期は、画面上のリポジトリタブをクリッ クすると実施されるのが既定の動作。リビジョン数が増えてくると表示されるまで に1分以上待たされる。 Redmine全体管理画面の「コミットを自動取得する」をOFFにして、Subversion リポジトリ側のPost-Commit-Hookに同期スクリプトを組み込むことで、同期ト リガが“コミット時”へ変更され、画面上のリポジトリタブは直ちに表示されるよう になる。 2)Subversionリポジトリの同期対象を指定する 前述のPost-Commit-Hookは全プロジェクトを対象にするため、リポジトリ数が多 い場合5分以上かかる場合がある。ほぼ同時に5人が5回ずつコミットすると同期が 25並列で実行されてしまい、処理輻輳によりRedmineが応答しなくなる。 特定のProjectのみ同期を実施するよう、スクリプトに追記する。
  124. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例2)【性能】リポジトリタブが遅い

    124 【チューニング要素】 ・H/W: HDD, Memory, CPU ・S/W: DBMS, Ruby, WebAppServer, Subversion Server ・N/W: 通信帯域, Switching-Hub 3)Subversionセッションキャッシュ セッション毎にキャッシュメモリを付与 (Subversion 1.7 以上) 4)Subversion通信圧縮機能 通信内容の圧縮レベル指定(Subversion 1.7 以上) 5)同一サーバーに置き、通信帯域を広くする Local loopback, TCP/UDP/Socket通信は高速 6)MySQL テーブル更新が遅い DBMSメモリ設定 SSD採用
  125. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例3)【性能】検索が遅い

    125 1)MySQLメモリチューニング ・メモリをできるだけ積み込む ・全インデックス、全データをオンメモリにする 2)カスタムフィールドの設定 「検索対象」の数が多いと極端に性能が落ちる 【チューニング要素】 ・H/W: Memory, CPU ・S/W: DBMS, Redmine
  126. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例4)【性能】画面応答が遅い

    126 1)Rubyのバージョン 処理性能 1.9 < 2.0 < < < 2.1 < 2.2 < 2.3 < 2.4 < 2.5 ≒ 2.6 2)MySQLメモリチューニング 全インデックスと主要データをメモリに乗せる 3)初回アクセスが極端に遅い MySQL 5.6以降 – Bufferpool save and load PostgreSQL 9.4以降 - pg_prewarm 4)CPUコア数と同時並行処理数 処理要求が集中した時の待ち行列 CPUコアやHTスレッド数に合わせて並行度を上げ、最大待ち時間を低く抑える - Passenger:自動調整 (指定も可能) - Thin:起動サーバー数を増減 【チューニング要素】 ・H/W: HDD, Memory, CPU ・S/W: OS, DBMS, Http Server, Ruby, WebAppServer ・N/W: 通信帯域, Switching-Hub
  127. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例4)【性能】画面応答が遅い

    127 5)メール非同期送信(Async) 通知先が多い / メールサーバー(MTA)が遅い 6)Plugin導入数 導入数が多いと遅くなる。 大量データの応答性能まで考慮されているPluginはそう多くない。 7)通信データの圧縮 HTTP1.1/Compression (最大10倍速) 【チューニング要素】 ・H/W: HDD, Memory, CPU ・S/W: OS, DBMS, Http Server, Ruby, WebAppServer ・N/W: 通信帯域, Switching-Hub
  128. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例5)【性能】特定プラグインが遅い

    128 【チューニング要素】 ・H/W: Memory, CPU ・S/W: DBMS, Ruby, WebAppServer - 一部のプラグインは大量のデータ処理を想定していない。 極端に遅い場合はチューニングを施し、作者にパッチを送付できる。 処理遅延の原因は、SQL/コード実装/データ設計の3系統に大別できる。 SQLとコード実装は何とか対処もできるが、データ設計は大がかりな変更を 伴うので、テストコードが無ければ諦める。 - 例)Work Time 10倍速(画面応答 12秒 → 1秒) プルリク https://bitbucket.org/tkusukawa/redmine_work_time/pull-request/17 ・SQL調査手順 SlowクエリやSQL実行計画の調査方法はDBMS製品毎に異なるが、 類似機能は必ず存在する。 参考資料)Yahoo Japan社内向けDBチューニングセミナー http://www.slideshare.net/techblogyahoo/mysql-58540246 ・アプリコード調査手順(今回は実施せず) ・データ設計調査手順 (今回は実施せず)
  129. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例6)【信頼性】不安定で手間がかかる

    129 1)3歩遅れの「枯れた技術」 末尾が3になったら導入 例)Redmine 4.0.3 2)Windows <<< Linux OS 両方面倒を見てきたが、Ruby, Rails はWindowsで制限が多い(印象) 3)RedmineUpdateの工夫 新旧の環境を並立させて動作を確認し、準備が整ったら切り替える 4)OSS パッチの取込み Redmineの性能が改善され、問題は解消され続けている。 最新版を手間なく取り込む方法がある。Gitの追跡ブランチモードで git cloneし、 Local変更との共存を確保しつつ、git pull で差分を取り込めば良い。 例)# mkdir /var/lib/its/rm40_its # cd /var/lib/its/rm40_its # git clone https://github.com/redmine/redmine.git . # git checkout -b 4.0-stable-local origin/4.0-stable # git pull (差分取り込み実行) 【チューニング要素】 ・H/W: Memory, CPU ・S/W: DBMS, Ruby, WebAppServer
  130. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例6)【信頼性】不安定で手間がかかる

    130 5)Exception発生をMail 通知し、不具合を確実に検出 Redmine本体のExceptionは9年間でもほんの僅か https://github.com/kou/redmine_exception_handler (Redmine4.0対応) 6)Redmine本体やRailsに手を入れない Redmine本体の品質は極めて高い テストコードのカバレッジ率がとても高い http://www.redmine.org/builds/coverage/ 7)Pluginは魅力的だが、採用は最小限に抑制 Redmine本体のUpdateの足枷になる テストコードが無く、DBテーブル構造を壊す例もある 【ITS運転結果(実績値)】 平均故障間隔(MTBF) 8,364時間(348日)、平均修復時間(MTTR) 15時間、稼働率 99.8% 言い換えると「SBSのITSサーバーは1年に1回故障し、システムサービスの復帰まで15時間かかる」 【チューニング要素】 ・H/W: Memory, CPU ・S/W: DBMS, Ruby, WebAppServer
  131. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例6)【信頼性】不安定で手間がかかる

    131 8)完全なクローン環境を常設 ・ゴミデータ、評価用データを本番に持ち込ませない ・要望を受けてから手動で同期 ・誤入力の事故を防止するため、画面の色を変えている 【チューニング要素】 ・H/W: Memory, CPU ・S/W: DBMS, Ruby, WebAppServer Dump and Restore
  132. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved Munin:

    Average latency Munin: Average latency 事例7)【性能】電算機のH/W資源不足 132 1)Redmine関係アプリケーションを1VMに集約し、狭帯域通信を回避 2)CPU キャッシュの大きなものを複数コア用意 同時接続の処理数に合わせる 3)メモリをできるだけ積み込む 4)SSD導入: SSD(OS, DBMS, Redmine)、HDD(その他データ) ↓ SSD切替点 ↓ SSD切替点 【HDD】突出ピークが無くなった。 【SSD】ピークが無くなりI/O waitが小さくなった。 振れ幅が小さく、余力が見てとれる。
  133. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例8)【性能】電算機通信網の帯域不足

    133 <Network> 1)主要通信経路は1G/bpsに統一 10M/bps, 100M/bps のボトルネックを排除 2)Normal Hub → Switching Hub コリジョン発生率の低減 3)Local Loopback通信 サーバー統合による通信の高速化
  134. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例9)【性能】起動が遅い

    134 <DBMSの起動・再起動直後、初回アクセスだけが極端に遅い> 1)DBMSサーバーの起動、再起動時は「暖機運転」が必要 「暖機運転」とは、DBMS再起動後にデータやインデックスを メモリ上へ読み込む一連の処理。対象となるデータが増えると、 長時間かかるようになる MySQL5.6系以降warm up 、 Postgresql 9.4系以降にpg_prewarmとして実装された BufferPool、Workloadの保存・読込機能によって待ち時間が大幅 に短縮される MySQL innodb_buffer_pool_dump_at_shutdown = ON innodb_buffer_pool_load_at_startup = ON
  135. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 設定例1)基本S/W

    135 OS, File-System 1)OS CentOS 7 プロセス、パッケージは必要最低限に削ぎ落とす。 (パッチ適用、最少の停止頻度、セキュリティー、メモリ) 2)File-System Ext4 nobarrier チューン http://goo.gl/LYwfA0 3)Kernel設定 ・[SSD] Disk I/O スケジューラーを cfq から deadline へ変更 ・[SSD] SWAP抑制 vm.swappiness=1 ※ 性能への影響は未確認
  136. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 設定例2)ミドルウェア

    136 DBMS, WebServer, Web Application Server <DBMS> 1)チューニング設定 ・MySQL 5.7 2)SSDによるI/O改善 ・DBMS設定 MySQL innodb_flush_neighbors = 0 ・配置構成 DBデータだけでなく、OS全体をSSDに乗せると効果が大きい ・結果例 200万チケット分のDBデータをダンプ/リストア HDD → SSDにより33%向上(5分早く終わる)
  137. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 設定例2)ミドルウェア

    137 DBMS, WebServer, Web Application Server <WebServer> 3)通信圧縮 Compress, Gzip, Deflate 圧縮 <Web Application Server> 4)選択 WEBLick は性能 × 運用の容易さは Unicorn < Passenger 5)Phusion Passenger 6 6)Passenger と OOBGC Passenger4, Ruby2.1, OOBGC(gctools)で安定稼働(実績1年) Passenger5, Ruby2.2, OOBGC(gctools)で安定稼働(実績6ヶ月) Passenger5, Ruby2.3, OOBGC(gctools)で安定稼働(実績2年) 7)Passenger Enterprise Multi Threadモードで◦◦% 向上 (未調査) 利用料金は 5000円/月程度
  138. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 設定例3)応用S/W

    138 Ruby, OOBGC, Redmine, Subversion <Ruby> ・GCの大幅改善によりRuby2.5が最速のバージョン(調査時点 2019/1 ) ・2位は Ruby2.3+OOBGC <OOBGC for Ruby2.1, 2.2, 2.3> ・Unicorn GitHubのAman gupta-san(@tmm1)が作ったgctools original. https://github.com/tmm1/gctools ・Passenger4/5 Ruby2.1は、Shirosaki-san(@shirosaki)のFork版 https://github.com/shirosaki/gctools Ruby2.1/2.2/2.3は、@akahane92 のFork版 https://github.com/akahane92/gctools This fork is based on Shirosaki-san(@shirosaki)’s gctools, and patched Ruby2.2+ modifications from Charlie Somerville(@charliesome)’s pull-request. https://github.com/tmm1/gctools/pull/14 → Ruby2.4, 2.5, 2.6は、Normalの採用が総合的に見て最適選択。 OOBGC有は最大性能への向上を必要とする方向け(ちょいムズ)
  139. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 設定例3)応用S/W

    139 Ruby, OOBGC, Redmine, Subversion <Redmine> ・カスタムフィールドの設定値「検索条件」の数を減らす。 例「14万チケットだと30種 ◦◦秒 → 5種 〇秒」 (未計測だが効果は絶大) ・メール非同期送信(Async) ※ Redmine4.0以降は不要(ActiveJobによる非同期の送信処理へ変更された) config/configuration.yml production: email_delivery: delivery_method: :async_smtp async_smtp_settings:
  140. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 設定例3)応用S/W

    140 Ruby, OOBGC, Redmine, Subversion <VCS> ・Subversion Server 1.7以降のセッションキャッシュ付与機能 セッションキャッシュにより、通信応答速度が向上する。 ・Subversion Server 1.7以降の通信圧縮機能 セッションデータ通信内容の多くはテキストデータ。 高い圧縮によって通信効率と応答性が向上する。
  141. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次

    141 第1部 背景と要求 第2部 チューニングの基本 第3部 ベンチマーク 第4部 全文検索機能の拡張 第5部 性能改善事例集 第6部 まとめ 141
  142. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved お話ししたこと

    142 1)200万チケットでもサクサク動くRedmineの全レシピ* 2)Redmine 2.6 を 4.0 へUpdateすると平均で29% 速くなる 3)Ruby2.2 を 2.5, 2.6 へUpdateすると平均で21.7% 速くなる 4)HDDをSSDにすると環境により平均で28.5% 速くなる 5)非索引型の全文検索は20~30万チケットで性能限界に到達 するが、Fulltext-Search-Plugin の導入によって23倍速くなり、 200万チケットの環境では平均1.9秒で全文検索できる 6)Redmine全文検索の機能の追加開発とオープンソース化 7) Redmineチューニング事例 9種 *全レシピ: 設定値の一括ダウンロードはこちら (GitHub Gist) Download: Setting_paramaters_for_Redmine_Performance_Tuning.txt https://gist.github.com/akahane92/771f9a52d81af9864dd8
  143. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved まとめ|実際

    143 ・初期値のままでは、1万チケットまで ・最低限のチューニングで、10万チケットまで(最新のWindows Bitnami) ・最低限のチューニングで、15万チケットまで(Linux, MySQL, Windowsスクラッチ) ・ある程度のチューニングで、200万チケットまで(Linux, MySQL) ・最大限のチューニング (必要としてないので今はやっていない) 処理並行度を上げる、高IOPsのDisk採用、DBMSのI/O最適化 例)Linux, MySQL: Nginx + Unicorn ロードバランサ + WebAppServerクラスタリング + DBMSクラスタリングと、SQL ProxyによるR/W, R/Oの分離、SSD PCIe
  144. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved まとめ|限界

    144 RedmineのFTS (非索引型) (Redmineは悪くないが)30万チケットを超えたあたりで検索が遅くなる。 例えばCPU4コアで稼働している時に、全プロジェクト横断の検索が4回ク リックされ、並行で実行されるとCPUが占有されてRedmineが無応答になっ てしまう。 また、 現在のSQL検索ではデータ量が増えると埋もれてしまい、探してい る情報がなかなか得られないという、検索精度の問題が明らかになった。 今回、 Full Text Search Plugin の性能向上による高速化と、スコアベース検 索による検索精度の改善が得られた。十分な性能を確認できたことから、検 索に関する懸念要素が払拭された。 現在4億5千万文字を記録・蓄積しており、今後も増加の一途にあるので、何 らかの索引型FTSサポートがRedmineに必要(標準機能が最善)。
  145. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved まとめ|限界

    145 Redmineのファイル内容 全文検索 添付ファイルの内容検索がパッチとして提供されている(Planio提供 #306)が、 大量の添付ファイルを検索対象とした場合、全文検索の性能は低いと予想される。 想定される課題は3点: 1)検索処理時間 実運用環境の35万ファイルを使用して、全文検索(非索引型)の応答性能を計測 すると、10億文字分の検索処理が長時間かかってしまい、日常的に使うには 性能が不足するだろう。将来のデータ増加を最大200億文字と想定すると、 このままでは厳しい。 → Full Text Searchプラグインによる、検索機能の拡張開発「添付ファイ ルの索引型高速全文検索」により改善できる(もうすぐ) 2)検索結果の精度 SQL検索では探している情報が大量のデータに埋もれてしまうため、見つける までに時間がかかってしまう。 → Full Text Searchプラグインによる、 検索機能の拡張開発「高精度検索」により改善できる(予定)
  146. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved まとめ|限界

    146 Redmineのファイル内容 全文検索 3)リポジトリ内容の検索機能が無いため、ソースコード検索、ドキュメント検索 ができず、効率が悪い。 → Full Text Searchプラグインによる、検索機能の拡張開発「リポジトリ内容 の索引型高速全文検索」により改善できる(予定)
  147. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録

    147 147
  148. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録|性能関連設定の一覧

    148 本稿で扱った性能ベンチ-マークは下記設定による。 1. 計測プログラム 2. Apache2.4, 2.2 HTTP/1.1 通信圧縮 3. Passenger 4. MySQL 5.7, 5.6 Linux, Bitnami 5. Subversion キャッシュ設定, 通信圧縮 6. Redmine Subversion同期 ProjectID指定 7. Redmine OOBGC for Unicorn and Passenger 8. OS File System 設定値の一括ダウンロードはこちら (GitHub Gist) Download: Setting_paramaters_for_Redmine_Performance_Tuning.txt https://gist.github.com/akahane92/771f9a52d81af9864dd8
  149. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録|計測方法

    149 計測プログラム # bench.rb # -*- coding: utf-8 -*- rv = ARGV[0] cashmode = ARGV[1] url_list = [ "/#{rv} ", "/#{rv}/projects ", "/#{rv}/projects/sscope ", "/#{rv}/issues?per_page=200 ", "/#{rv}/issues/1 ", "/#{rv}/issues/47548 ", "/#{rv}/issues/51782 ", "/#{rv}/projects/its-issues/wiki " ] puts "--- Environment ---" puts `httpd -version` puts `ruby -v` puts `gem list --local passenger` puts `export RAILS_ENV=production; /var/lib/its/#{rv}/script/about` puts `export RAILS_ENV=production; /var/lib/its/#{rv}/bin/about` puts `export RAILS_ENV=production; cd /var/lib/its/#{rv}; bundle list` ti = 5 result = [] url_list.each { |url| rate_avg = 0 ms_avg = 0 puts "--- #{url} ---" ti.times { res = `httperf --hog --server=localhost --port=80 --uri=#{url} --num-conns 2 --num-calls 10 2> /dev/null | grep 'Request rate:' | awk '{print$3,$5}' | sed -e 's/(//'` num = res.split(' ').map{|s| s.to_f} puts " rate: #{num[0]} req/s #{num[1]} ms/req" rate_avg += num[0] ms_avg += num[1] sleep 0.2 } rate_avg = (rate_avg/ti).round(1) ms_avg = (ms_avg/ti).round(1) result << [rate_avg, ms_avg] puts " AVG: #{rate_avg} req/s #{ms_avg} ms/req" } rate_avg_total = (result.transpose[0].inject(:+)).round(1) ms_avg_total = (result.transpose[1].inject(:+)).round(1) puts "-------------------------" result.size.times { |r| puts "#{r+1} ¥t #{url_list[r]} ¥t #{result[r][0]} ¥t #{result[r][1]}" } puts "#{cashmode} ¥t Total ¥t #{rate_avg_total} ¥t #{ms_avg_total}" puts "-------------------------" result.size.times { |r| puts " AVG Rate: #{result[r][0]} req/s (#{result[r][1]} ms/req)" }
  150. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録|Apache2.4,

    2.2 150 Apache2.4 /etc/httpd/conf.d/defelate.conf <IfModule mod_deflate.c> SetOutputFilter DEFLATE DeflateCompressionLevel 1 DeflateMemLevel 8 # LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate # CustomLog /var/log/httpd/deflate_log deflate <Location /> # MSIE masquerades as Netscape, but it is fine BrowserMatch ¥bMSIE¥s(7|8) !no-gzip !gzip-only-text/html FilterDeclare Compression CONTENT_SET FilterProvider Compression DEFLATE "%{CONTENT_TYPE} = 'text/html'" FilterProvider Compression DEFLATE "%{CONTENT_TYPE} = 'text/plain'" FilterProvider Compression DEFLATE "%{CONTENT_TYPE} = 'text/css'" FilterProvider Compression DEFLATE "%{CONTENT_TYPE} = 'text/javascript'" FilterProvider Compression DEFLATE "%{CONTENT_TYPE} = 'text/xml'" FilterProvider Compression DEFLATE "%{CONTENT_TYPE} = 'application/xhtml'" FilterProvider Compression DEFLATE "%{CONTENT_TYPE} = 'application/xml'" FilterProvider Compression DEFLATE "%{CONTENT_TYPE} = 'application/xhtml+xml'" FilterProvider Compression DEFLATE "%{CONTENT_TYPE} = 'application/rss+xml'" FilterProvider Compression DEFLATE "%{CONTENT_TYPE} = 'application/atom+xml'" FilterProvider Compression DEFLATE "%{CONTENT_TYPE} = 'application/javascript'" FilterProvider Compression DEFLATE "%{CONTENT_TYPE} = 'image/svg-xml'" FilterChain Compression # Don't append Vary heder for specific files SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png|t?gz|zip|bz2|sit|rar|lzh|exe)$ dont-vary # Make sure proxies don't deliver the wrong content Header append Vary Accept-Encoding env=!dont-vary </Location> </IfModule> Apache2.2 /etc/httpd/conf.d/defelate.conf <IfModule mod_deflate.c> DeflateCompressionLevel 2 # LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate # CustomLog /var/log/httpd/deflate_log deflate <Location /> # Netscape 4.x has some problems... BrowserMatch ^Mozilla/4 gzip-only-text/html # Netscape 4.06-4.08 have some more problems BrowserMatch ^Mozilla/4.0[678] no-gzip # MSIE masquerades as Netscape, but it is fine BrowserMatch bMSIE !no-gzip !gzip-only-text/html FilterDeclare Compression CONTENT_SET FilterProvider Compression DEFLATE resp=Content-Type $text/html FilterProvider Compression DEFLATE resp=Content-Type $text/xml FilterProvider Compression DEFLATE resp=Content-Type $text/css FilterProvider Compression DEFLATE resp=Content-Type $text/plain FilterProvider Compression DEFLATE resp=Content-Type $image/svg+xml FilterProvider Compression DEFLATE resp=Content-Type $application/xhtml+xml FilterProvider Compression DEFLATE resp=Content-Type $application/xml FilterProvider Compression DEFLATE resp=Content-Type $application/rdf+xml FilterProvider Compression DEFLATE resp=Content-Type $application/rss+xml FilterProvider Compression DEFLATE resp=Content-Type $application/atom+xml FilterProvider Compression DEFLATE resp=Content-Type $text/javascript FilterProvider Compression DEFLATE resp=Content-Type $application/javascript FilterProvider Compression DEFLATE resp=Content-Type $application/x-javascript FilterProvider Compression DEFLATE resp=Content-Type $application/x-font-ttf FilterProvider Compression DEFLATE resp=Content-Type $application/x-font-otf FilterProvider Compression DEFLATE resp=Content-Type $font/truetype FilterProvider Compression DEFLATE resp=Content-Type $font/opentype FilterChain Compression # Don't append Vary heder for specific files SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png|t?gz|zip|bz2|sit|rar|lzh|exe)$ dont-vary # Make sure proxies don't deliver the wrong content Header append Vary User-Agent env=!dont-vary Header append Vary Accept-Encoding env=!dont-vary </Location> </IfModule> 1. HTTP/1.1 通信圧縮
  151. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録|Passenger

    151 Apache2 /etc/httpd/conf.d/passenger.conf # Rails environment settings RailsEnv production # Multiple Redmine Envirnoment with Sub-URI RailsBaseURI /its26 RailsBaseURI /its30 RailsBaseURI /its31 RailsBaseURI /its32 RailsBaseURI /its33 RailsBaseURI /its34 RailsBaseURI /its40 # Remove http headers added by Passenger. Header always unset "X-Powered-By" Header always unset "X-Rack-Cache" Header always unset "X-Content-Digest" Header always unset "X-Runtime" # Tuning Parameters for Passenger. PassengerMaxPoolSize 20 PassengerMaxInstancesPerApp 4 PassengerPoolIdleTime 3600 PassengerHighPerformance on PassengerStatThrottleRate 10 RailsSpawnMethod smart RailsAppSpawnerIdleTime 86400 PassengerMaxPreloaderIdleTime 0 # For OOBGC < Experimental > # PassengerSpawnMethod direct
  152. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録|MySQL

    5.7 152 <続き> default_storage_engine = InnoDB explicit_defaults_for_timestamp = 1 # For SSD innodb_flush_neighbors = 0 #innodb_page_size = 4K innodb_io_capacity = 2000 innodb_io_capacity_max = 6000 innodb_lru_scan_depth = 2000 # MySQL Server System Variables # http://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER join_buffer_size = 128M sort_buffer_size = 1M query_cache_type = 1 query_cache_size = 128M query_cache_limit = 6M tmp_table_size = 512M max_heap_table_size = 1G read_rnd_buffer_size = 16M key_buffer_size = 32M max_allowed_packet = 16M read_buffer_size = 1M bulk_insert_buffer_size = 64M max_connections = 100 character-set-server = utf8 skip-external-locking thread_cache_size = max_connections/3 table_open_cache = 4096 table_open_cache_instances = 64 performance_schema = OFF back_log = 50 + (max_connections / 5) expire_logs_days = 7 open_files_limit = 65500 max_prepared_stmt_count = 65528 innodb_print_all_deadlocks = ON MySQL 5.7 my.cnf # For advice on how to change settings please see # http://dev.mysql.com/doc/refman/5.7/en/server-configuration-defaults.html [mysqld] init-connect = SET NAMES utf8 default_password_lifetime = 0 server-id = 1 # InnoDB Paramaters # http://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html innodb_buffer_pool_dump_at_shutdown = ON innodb_buffer_pool_load_at_startup = ON innodb_buffer_pool_size = 8G innodb_log_file_size = 4G innodb_log_buffer_size = 8M innodb_flush_log_at_trx_commit = 1 innodb_log_files_in_group = 2 innodb_thread_concurrency = 16 innodb_concurrency_tickets = 5000 innodb_old_blocks_time = 1000 innodb_open_files = 300 innodb_stats_on_metadata = 0 innodb_checksum_algorithm = crc32 innodb_max_dirty_pages_pct = 90 innodb_lock_wait_timeout = 120 innodb_print_all_deadlocks = ON innodb_data_file_path = ibdata1:10M:autoextend innodb_autoextend_increment = 64 innodb_flush_method = O_DIRECT innodb_read_io_threads = 8 innodb_write_io_threads = 8 innodb_buffer_pool_instances = 8 innodb_rollback_segments = 32
  153. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録|MySQL

    5.6 153 <続き> default_storage_engine = InnoDB explicit_defaults_for_timestamp = 1 # For SSD innodb_flush_neighbors = 0 # MySQL Server System Variables # http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES join_buffer_size = 128M sort_buffer_size = 1M query_cache_type = 1 query_cache_size = 128M query_cache_limit = 6M tmp_table_size = 512M max_heap_table_size = 1G read_rnd_buffer_size = 16M key_buffer_size = 32M max_allowed_packet = 16M read_buffer_size = 1M bulk_insert_buffer_size = 64M max_connections = 100 character-set-server = utf8 skip-external-locking thread_cache_size = max_connections/3 table_open_cache = 4096 table_open_cache_instances = 64 performance_schema = OFF open_files_limit = 65500 max_prepared_stmt_count = 65528 MySQL 5.6 my.cnf # For advice on how to change settings please see # http://dev.mysql.com/doc/refman/5.6/en/server-configuration-defaults.html [mysqld] init-connect = SET NAMES utf8 # InnoDB Paramaters # http://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html innodb_buffer_pool_dump_at_shutdown = ON innodb_buffer_pool_load_at_startup = ON innodb_buffer_pool_size = 8G innodb_log_file_size = 4G innodb_log_buffer_size = 8M innodb_flush_log_at_trx_commit = 1 innodb_log_files_in_group = 2 innodb_thread_concurrency = 16 innodb_concurrency_tickets = 5000 innodb_old_blocks_time = 1000 innodb_open_files = 300 innodb_stats_on_metadata = 0 innodb_checksum_algorithm = crc32 innodb_file_format = Barracuda innodb_max_dirty_pages_pct = 90 innodb_lock_wait_timeout = 120 innodb_print_all_deadlocks = ON innodb_data_file_path = ibdata1:10M:autoextend innodb_autoextend_increment = 64 innodb_flush_method = O_DIRECT innodb_read_io_threads = 8 innodb_write_io_threads = 8 innodb_buffer_pool_instances = 8 innodb_rollback_segments = 32 innodb_use_sys_malloc = 1
  154. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録|MySQL

    5.6 for Bitnami 154 MySQL 5.6 my.cnf for Bitnami # The MySQL server [mysqld] # set basedir to your installation path basedir=C:/Bitnami/REDMIN~1.0-2/mysql # set datadir to the location of your data directory datadir=C:/Bitnami/REDMIN~1.0-2/mysql/data port=3306 character-set-server=UTF8 collation-server=utf8_general_ci max_allowed_packet=16M bind-address=127.0.0.1 # The default storage engine that will be used when create new tables when default-storage-engine=INNODB #================================================================ # InnoDB Paramaters # http://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html innodb_buffer_pool_size = 2G innodb_log_file_size = 512M innodb_thread_concurrency = 8 innodb_additional_mem_pool_size = 16M innodb_buffer_pool_dump_at_shutdown = ON innodb_buffer_pool_load_at_startup = ON # MySQL Server System Variables # http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html join_buffer_size = 128M sort_buffer_size = 1M query_cache_type = 1 query_cache_size = 64M query_cache_limit = 2M tmp_table_size = 64M max_heap_table_size = 64M #================================================================
  155. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録|Subversion

    キャッシュ&通信圧縮 155 Apache2.4, 2.2 /etc/httpd/conf.d/subversion.conf <IfModule dav_svn_module> SVNCompressionLevel 1 SVNInMemoryCacheSize 128000 SVNCacheFullTexts on SVNCacheTextDeltas on </IfModule>
  156. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録|

    Redmine Subversion同期 156 Subversion Post-Commit-Hook - post-commit #!/bin/sh # Redmine のプロジェクト名とSubversionリポジトリ名が一致している条件下でのスクリプト # 名称不一致の場合、本スクリプト中に名称を指定すればよい。(数が多いと面倒なのでお勧めしません) # (APIKEYは、 $REPOSHOME/common/APIKEY というファイルに記述) export LANG="ja_JP.UTF8" REPOS="$1" REV="$2" # Send E-Mail ${REPOS}/hooks/commit-email.rb "$REPOS" "$REV" # Sync SVN Repo with ITS REPOSHOME=`/usr/bin/dirname $REPOS` APIKEY=`/bin/cat $REPOSHOME/common/APIKEY` PJNAME=`/bin/basename $REPOS` URL="http://localhost/its/sys/fetch_changesets?id=$PJNAME&key=$APIKEY" /usr/bin/wget -q --no-proxy $URL -O /dev/null
  157. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録|

    Redmine OOBGC for Unicorn 157 Unicornへのgctools導入 (参考) http://tmm1.net/ruby21-oobgc/ http://qiita.com/jemiam/items/5c6e4595f3565f3c5562 Cookpad さんでは2016年1月末からgctoolsの利用を止める模様 http://k0kubun.hatenablog.com/entry/2016/01/23/231213 一方で、GitHub StaffのCharlie Somerville (@chariesome) は gctoolsのruby2.2+パッチを作ってプルリクを通し、 gctoolsは2016/2/11に0.2.4へアップデートされた。 Aman Gupta @tmm1 gctools for Ruby 2.1 (GitHub) https://github.com/tmm1/gctools # For Unicorn Ruby2.1, 2.2+
  158. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録|

    Redmine OOBGC for Passenger 158 Passengerへの gctools導入 ▪About gctools Aman Gupta @tmm1 gctools for Ruby 2.1 (GitHub) http://tmm1.net/ruby21-oobgc/ Passenger (Hongli Lai on) http://old.blog.phusion.nl/2014/01/31/phusion-passenger-now-supports-the-new-ruby-2-1-out-of-band-gc/ ▪ gctool gemのローカルビルド&インストール (For Passenger) cd /usr/local/src git clone https://github.com/shirosaki/gctools # For Ruby2.1 # または git clone https://github.com/akahane92/gctools # For Ruby2.1, 2.2, 2.3 gem build gctools.gemspec gem install gctools-0.2.3.gem ▪Passengerとgctools を Gemfile.localに追記 gem 'passenger' gem "gctools", '0.2.3'
  159. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録|

    Redmine OOBGC for Passenger 159 ▪config.ru パッチ diff --git config.ru config.ru index 2a89752..e3f49e6 100644 --- config.ru +++ config.ru @@ -1,4 +1,28 @@ # This file is used by Rack-based servers to start the application. require ::File.expand_path('../config/environment', __FILE__) -run RedmineApp::Application + +# ================================================== +if defined?(PhusionPassenger) + require "gctools/oobgc" + GC::OOB.setup + PhusionPassenger.require_passenger_lib 'rack/out_of_band_gc' + use PhusionPassenger::Rack::OutOfBandGc, :strategy => :gctools_oobgc, frequency: 5 + + PhusionPassenger.on_event(:oob_work) do + # Phusion Passenger has told us that we're ready to perform OOB work. + t0 = Time.now + GC.start + Rails.logger.info "Out-Of-Bound GC finished in #{Time.now - t0} sec" + end +end +# ================================================== + +#if ENV['RAILS_RELATIVE_URL_ROOT'] +# map ENV['RAILS_RELATIVE_URL_ROOT'] do +# run RedmineApp::Application +# end +#else + run RedmineApp::Application +#end
  160. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録|

    Redmine OOBGC for Passenger 160 Passengerへの gctools導入 ▪ /etc/httpd/conf.d/passenger.conf にOOBGC用の設定値を指定 # For OOBGC < Experimental > PassengerSpawnMethod direct
  161. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録|OS

    File System 161 ▪/etc/fstab /dev/mapper/vg_sms01-lv_root / ext4 defaults,nobarrier,noatime,discard 1 1 UUID=f94716b2-52d4-4e81-9a82-xxxxxxxxxxxx /boot ext4 defaults,discard 1 2 /dev/mapper/vg_sms01ex-lv_opt /opt xfs defaults,nobarrier,noatime 1 2 /dev/mapper/vg_sms01-lv_swap swap swap defaults,nobarrier,discard 0 0 注意:ディスクにアクセスできなくなったり、システム・アプリケーションが正しく動作しなくなる危険性があります。 バックアップを確保したうえで、理解できる方だけ自己責任でチャレンジしてください。 危険性が高いわりに、性能向上は体感しにくいので、専門家以外には推奨しません。
  162. 終 Special Thanks to ブログ等で技術情報を公開して下さったみなさま 西川 撒さん My Family.