SlideShare a Scribd company logo

Redmineチューニングの実際と限界(旧資料) - Redmine performance tuning(old), See Below.

•
•
Kuniharu（州晴） AKAHANE（赤羽根）
Kuniharu（州晴） AKAHANE（赤羽根）

* 最新版（2019/1）のスライドはこちら。Latest slides on Speaker Deck. https://goo.gl/VDSX9N

1 of 158
Downloaded 257 times
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大阪 株式会社島津ビジネスシステムズ 基盤技術部 赤羽根 州晴 kakahane@sbs.shimadzu.co.jp
2 ありがとう｡ Thanks a lot. Merci beaucoup.
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 話者紹介 赤羽根 州晴（@akahane92） 島津製作所 業務系システム子会社 ・ソフトウェア開発技術者 ↓障害対策専任 ↓内部統制 ・基盤技術標準化 (現在) 3 参加団体 ・Redmine大阪 ・AFFORDD 関西部会
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved お話しすること 4 １）200万チケットでもサクサク動くRedmineの全レシピ* ２）Redmine2.6 を 3.4 へUpdateすると平均で○○％速くなる ３）Ruby2.0 を 2.4 へUpdateすると平均で○○％速くなる ４）HDDをSSDに変更すると平均で○○％速くなる ５）非索引型の全文検索は○○万チケットで性能限界に到達するが、 FTS-Pluginの導入によって○○倍速くなり、 200万チケットの環境で平均○○～○○秒で全文検索できる ６） Redmineチューニング事例 9種 *全レシピ： 設定値の一括ダウンロードはこちら (GitHub Gist) Download: Setting_paramaters_for_Redmine_Performance_Tuning.txt https://gist.github.com/akahane92/771f9a52d81af9864dd8
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved お話ししないこと 5 １）大規模な並列トランザクション ２）DBMSチューニングの秘境探索
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ご注意 6 本発表の内容には様々な設定が含まれていますが、 ご利用は自己責任でお願い致します。 参考になさった場合に生じたいかなる損害も補償できません。 あらかじめご了承下さい。
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved Redmine使用状況 (アンケート結果） 7 使用しているRedmineは？ 有効回答数 69件、複数回答 （2017/8/26 Redmine大阪 #17） Redmine 3.0～3.3 65% Redmineを使用していない 17% Redmine 3.4.x 8% Redmine 2.x 10% Redmine 3.0～3.3 Redmineを使用していない Redmine 3.4.x Redmine 2.x Redmine 0.x Redmine 1.x trunk
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved Redmine使用状況 (アンケート結果） 8 使用しているRedmineは？ 有効回答数 69件、複数回答 （2017/8/26 Redmine大阪 #17） Redmine 3.0～3.3 65% Redmineを使用していない 17% Redmine 3.4.x 8% Redmine 2.x 10% Redmine 3.0～3.3 Redmineを使用していない Redmine 3.4.x Redmine 2.x Redmine 0.x Redmine 1.x trunk Redmine3.x ：73％ Redmine2.x ：10％ 未使用 ：15％
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved Redmine使用状況 (アンケート結果） 9 Redmineの環境と構築方法は？ ソース入手 （Linux), 21% 使用していない, 19% Bitnami(Window s), 15% Bitnami(Linux), 11% ソース入手 （Win), 11% 11% 6% 4% 0% ソース入手（Linux) 使用していない Bitnami(Windows) Bitnami(Linux) ソース入手（Win) その他 クラウドサービス VMイメージ RPM等パッケージ ソース入手（MacOS) ソース入手（JRuby) ALMinium 有効回答数 69件、複数回答 （2017/8/26 Redmine大阪 #17）
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved Redmine使用状況 (アンケート結果） 10 Redmineの環境と構築方法は？ 有効回答数 62件、複数回答 （2017/8/26 Redmine大阪 #17） ソース入手 （Linux), 21% 使用していない, 19% Bitnami(Window s), 15% Bitnami(Linux), 11% ソース入手 （Win), 11% 11% 6% 4% 0% ソース入手（Linux) 使用していない Bitnami(Windows) Bitnami(Linux) ソース入手（Win) その他 クラウドサービス VMイメージ RPM等パッケージ ソース入手（MacOS) ソース入手（JRuby) ALMinium UNIX Like ：48％ Windows ：32％ その他 ：20％
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved Redmine使用状況 (アンケート結果） 11 Redmineの使用年数は？ 有効回答数 69件、複数回答 （2017/8/26 Redmine大阪 #17） 3年以上 47% 使用していない 15% 使い始めたばかり 12% 1～3年ぐらい 15% 1年ぐらい 11% 3年以上 使用していない 使い始めたばかり 1～3年ぐらい 1年ぐらい
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved Redmine使用状況 (アンケート結果） 12 Redmineの使用年数は？ 有効回答数 69件、複数回答 （2017/8/26 Redmine大阪 #17） 3年以上 47% 使用していない 15% 使い始めたばかり 12% 1～3年ぐらい 15% 1年ぐらい 11% 3年以上 使用していない 使い始めたばかり 1～3年ぐらい 1年ぐらい 使用者 85%
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 教えて下さい 13 Redmine ・遅いと感じている方は？ ・性能チューニング経験は？ ・使用しているDBMSは？ （Postgresql、MySQL、SQLite、他） Eric Peacock https://www.flickr.com/photos/evilpeacock/6365513881/
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次 14 第１部 背景と要求 第２部 チューニングの基本 第３部 ベンチマーク 第４部 性能改善事例集 第５部 まとめ 第６部 付録 14
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次 15 第１部 背景と要求 第２部 チューニングの基本 第３部 ベンチマーク 第４部 性能改善事例集 第５部 まとめ 第６部 付録 15
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 株式会社 島津製作所 2017年3月31日現在 創 業｜ 設 立｜ 資 本 金｜ 従 業 員 数 ｜ 3,422億円 (2017年3月期)グループ売上高｜ 社 是｜科学技術で社会に貢献する 経営理念｜｢人と地球の健康｣への願いを実現する 16 11,528名 (連結) 明治8（1875）年 大正6（1917）年 266億円
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事業領域 産業機器 航空機器医用機器 分析・計測機器 17
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要 18 島津製作所グループ 業務システム 情報系 子会社委託 IT全般統制 ISO 内部統制 省庁監査
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要 19 島津製作所グループ 業務システム 情報系 子会社委託 IT全般統制 ISO 他 内部統制 省庁監査 複数の統制･認証に対応 大量の記録が必要
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜背景モデル 20 要 件 結 果 業務用ITシステムの全般的な管理記録は 内部統制や各種認証（ISO,ISMS,省庁監査）の 要求に答えなければならない •記録と整合 •精査と承認 •追跡可能性 •目的合理性 •品質管理 •セキュリティー
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜背景モデル 21 課題 3 課題・要望 問合せ受付 調査と確認 状況報告 方針決定 対処と確認 結果報告 時 間課題 2 変更 問合せ受付 調査と確認 状況報告 方針決定 対処と確認 結果報告 時 間課題 １ トラブル 問合せ受付 調査と確認 状況報告 方針決定 対処と確認 結果報告 時 間複数 ユーザー複数 ユーザー 複数 ユーザー 複数 ユーザー複数 ユーザー 複数 担当者 C事業部 B事業部 A事業部 X System Y System Z System 関係者増加 ／ 事案多様化／システム増加・分散 N ： N ： N
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜業務システムの運営状況 22 業務システム １００種 利用者 7000人 事案 36000件 改版(コミット) 20000回 1700 KLOC 開発運用 ２００人 ／年 ／年 ／年 自動生成コード含む７～２0年超
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜問題要約 23 1. 人の記憶が頼り「生き字引き」 2. システム毎の管理台帳で 情報お蔵入り 3. 経緯は 担当者のMail-Box に蓄積 4. システムと組織の壁が情報流通を阻害 5. パートナー契約、引継ぎ不足 6. 横断検索できない 7. ツールが現実を表現できない 8. 統制･監査･査察への対応負担増
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜解決策 24 統合管理 全面導入 Issue Tracking System
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜事案関係モデル 3.6万件／年 ２万コミット／年 ／年 関係性 25 記憶の消滅 × 二次元 Excel 表現できる…何か
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜事案関係モデル 3.6万件／年 ２万コミット／年 ／年 関係性 26 記憶の消滅 × 二次元 Excel ITS OSS
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜ITS導入の全体像 27 Project A 問合せ 要望･課題 障害･バグ タスク Project B 問合せ 要望･課題 障害･バグ タスク 課題管理システム (ITS) 版数管理ツール ■日常業務に浸透 •トータルで負担減少 •状態の掌握が容易 •コミュニケーション促進 ■トレーサビリティー 一意性 永続的な 連鎖性 履歴追跡性 ■変化への適応 状況変化を記録し追従 後々の参照が容易に SVN
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜放置チケット対策の定着 28 週次ミーティングで、 積極的にチケット完了 ITSを使った会議
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要 ・プロジェクト数、ユーザー数の経年変化 29 0 50 100 150 200 250 300 350 400 450 500 0 20 40 60 80 100 120 140 160 180 200 2010 2011 2012 2013 2014 2015 2016 2017 プロジェクト数 ITSユーザー数 ユ ー ザ ー 数 プ ロ ジ ェ ク ト 数 Project数182 User数 459 調査日 2017/7
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜チケットの発行数と完了率 30 調査日 2017/7 0 10 20 30 40 50 60 70 80 90 100 0 5,000 10,000 15,000 20,000 25,000 30,000 35,000 40,000 45,000 50,000 2010 2011 2012 2013 2014 2015 2016 2017 完 了 率 チ ケ ッ ト 発 行 数 Ticket発行数 完了率 近似曲線（線形） 完了率 87% → 93% 累計 26万件 3,500/月 ％
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 20 40 60 80 100 120 140 160 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 2010 2011 2012 2013 2014 2015 2016 2017 完 了 所 要 日 数 の 平 均 完 了 所 要 日 数 の 分 布 6ヶ月以上 6ヶ月 3ヶ月 1ヶ月 2週間 1週間 1日 平均完了日数 概要｜完了所要日数の分布と平均 調査日 2017/7 日 2011年 147日 2016年 41日
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜チケット説明欄の文字数変化 32 0 100 200 300 400 500 600 700 800 900 1000 0 5,000 10,000 15,000 20,000 25,000 30,000 35,000 40,000 45,000 2009 2010 2011 2012 2013 2014 2015 2016 2017 チ ケ ッ ト 毎 の 記 録 文 字 数 チ ケ ッ ト 発 行 数 チケット発行数 説明欄文字数（平均） 近似曲線（線形） 2011年 529文字 2016年 738文字 調査日 2017/7 2016年 2億7千万文字 2017年 3億3千万文字 文字
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 2010 2011 2012 2013 2014 2015 2016 2017 チ ケ ッ ト 毎 の 添 付 フ ァ イ ル 数 チ ケ ッ ト 発 行 数 チケット発行数 添付ファイル数 1チケット毎の添付数 概要｜添付ファイル数の経年変化 33 ファイル 調査日 2017/7 2017年 26万3千 ファイル
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜チケット関係性の経年変化 34 関係性カウント 線をカウントする 例）３カウント Ticket Ticket Ticket Ticket 関係記録数 2011年 11% 2015年 22% 調査日 2016/9 0% 5% 10% 15% 20% 25% 30% 0 5 10 15 20 25 2010 2011 2012 2013 2014 2015 2016 関 係 保 持 割 合 チ ケ ッ ト 発 行 数 の 累 計 万 チケット発行数累計 関係数累計 関係保持割合 線形 (関係保持割合)
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 20 40 60 80 100 120 140 160 180 0 500 1,000 1,500 2,000 2,500 3,000 2010 2011 2012 2013 2014 2015 2016 2017 完 了 所 要 日 数 平 均 障 害 ・ バ グ チ ケ ッ ト 数 障害・バグチケット数 完了所要日数平均 概要｜障害･バグチケット数と完了所要日数の平均 35 調査日 2017/7 No Ticket, No Commit 開始 日 所要日数平均 157日 → 56日
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜｢障害･バグ｣チケット密度 36 0 10 20 30 40 50 60 70 80 90 0 5,000 10,000 15,000 20,000 25,000 30,000 35,000 40,000 45,000 2011 2012 2013 2014 2015 2016 2017 障 害 ・ バ グ チ ケ ッ ト 密 度 チ ケ ッ ト 発 行 数 チケット発行数 障害･バグチケット発行数 障害･バグチケット密度 障害･バグチケット密度 (Spike除去) 2012年 59件/KT 2016年 52件/KT 調査日 2017/7 件／KT (Kilo Ticket)
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜監査手続の定性評価 37 【例示】｢全てのIT統制対象システムにおいて、任意の 6ヶ月間に発生した全ての変更事案の中から、設計書と プログラムの両方、或いはいずれかを変更し、かつ、 データ強制変更を伴う事案の一覧を提出。ここから25 件をサンプリングし承認行為を示す証憑･証跡を提出｣ ３時間以内 複数人がかりで ２〜３日
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜まとめ 38 統制実現 コスト低減 属人性軽減 品質, CS向上 業績貢献 【経営要求】 【現場要求】 現業務を表現可能 入力コストに見合う いつでもどこでも 素早く見つかる 休みやすい 【管理手法】 【統制要求】 IT全般統制 ISO 省庁監査 一意識別 ↓ 関連維持 ↓ 追跡可能 ↓ 信頼可能 現場の利益を動機とする 部分最適型の行動規範 が、結果として経営要求 を満たす統合情報基盤と して、全体最適型の均衡 を得た
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜まとめ 39 １）100種の業務システムを200人が運用する現場 ２）IT統制に対応するため高水準の管理品質を維持 網羅性は必達（全員が全情報を入力し続ける） ３）文房具：常にサクサクの応答性能と盤石な安定性 ４）運営のための余力は皆無。省力化の徹底と、 安定性･信頼性の同時成立が不可欠（さもないと帰れない）
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次 40 第１部 背景と要求 第２部 チューニングの基本 第３部 ベンチマーク 第４部 性能改善事例集 第５部 まとめ 第６部 付録 40
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次 41 第１部 背景と要求 第２部 チューニングの基本 第３部 ベンチマーク 第４部 性能改善事例集 第５部 まとめ 第６部 付録 41
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本 42図引用元： http://ja.wikipedia.org/wiki/ボトルネック概念図.png
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本 43図引用元： http://ja.wikipedia.org/wiki/ボトルネック概念図.png 電子計算機 ネットワークシステム ボトルネックの 発見と解消
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本  ボトルネックはどこか？ 44 ＃ 対 象 対 策 例 １ 通信 狭帯域を回避 Ethernet ２ 情報量 圧縮 HTML, Text ３ 電子計算 再処理を回避 多段キャッシュ ４ 永続化 高速装置へ置換 HDD ５ アルゴリズム 算法選択による 計算量削減 Sort, Index, GC
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本  対策１ 狭帯域通信を避ける 45 Ethernet等の 低速通信 2M, 10M, 100Mbit / 秒 経路上の最も狭い帯域
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved Local Loopback adapter 同一OS内のTCP/UDP/Socket通信 チューニングの基本  対策１ 狭帯域通信を避ける 46 狭帯域 ６→３
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本  対策２ 情報量の圧縮 47 HTTP/1.1 Compression 情報量 1/4 ～ 1/10 最大10倍速
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本  対策３ 再処理回避 48 Server Pass enge r RAID OS FS NW Ruby Rails Redmine DBMS HTTP Reverse Proxy Client Browser JavaScript / DOM OS FS NW
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本  対策３ 再処理回避 49 Server Pass enge r RAID OS FS NW Ruby Rails Redmine DBMS HTTP Reverse Proxy Client Browser JavaScript / DOM OS FS NW ㋖㋖ ㋖㋖ ㋖ ㋖ ㋖ ㋖ ㋖ ㋖ ㋖ ㋖ ・潤沢なメモリ ・多段キャッシュ
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本  対策４ 永続化 50* 情報の永続化 「電源をOFFにしてもデータが消えないようにすること」 Server Pass enge r RAID OS FS NW Ruby Rails Redmine DBMS HTTP Reverse Proxy 情報の永続化* SSDの登場 劇的な速度向上
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本  対策５ 算法選択による計算量削減 51 算法の選択による 速度向上* Sort, GC, Index * 算法の変更によって計算処理量を減らし、より少ない時間で同一の処理を実施する Server Pass enge r RAID OS FS NW Ruby Rails Redmine DBMS HTTP Reverse Proxy
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本  チューニング要点 52 Passenger5.1 OS CentOS7 （64bit） Ruby 2.4 Rails4.2 Redmine 3.4 DBMS MySQL 5.6 HTTP Apache 2.4 Memory 4〜16GBCPU 4〜6 Cores VMware （可用性、信頼性） VCS Subversion 1.8 HTTP Reverse Proxy --- ：8 Key Points Network
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本  チューニング要点 53 Passenger5.1 OS CentOS7 （64bit） Ruby 2.4 Rails4.2 Redmine 3.4 DBMS MySQL 5.6 HTTP Apache 2.4 Memory 4〜16GBCPU 4〜6 Cores VMware （可用性、信頼性） VCS Subversion 1.8 HTTP Reverse Proxy --- ：8 Key Points Network Redmine本体は変更しない 安定、安全、信頼
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次 54 第１部 背景と要求 第２部 チューニングの基本 第３部 ベンチマーク 第４部 性能改善事例集 第５部 まとめ 第６部 付録 54
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次 55 第１部 背景と要求 第２部 チューニングの基本 第３部 ベンチマーク 第４部 性能改善事例集 第５部 まとめ 第６部 付録 55
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク 56 【背景】 ・年間36,000チケットを起票 ・業務の中心にITS（Redmine） ・処理遅延や障害停止の回避は必須 【2012年10月】 ・ITSの業務活用が急拡大（10万チケット越） ・200万チケットまでの動作を先行して確認 ・問題を洗い出して対策 【2015年5月、2016年3月、2017年7月】 ・2012年の予測値と、今までの実績値を比較 ・Redmine, Ruby, Rails, H/Wの変化 ・再度、性能ベンチマークを計測して最適解を選ぶ
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク 57 “サクサク”の 基準
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク 58 画面応答時間の基準*とは？ 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
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク 59 画面応答時間の基準*とは？ 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は文房具
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜実績値 60 Redmine月間アクセス数*の経年変化 * 8年分のApache アクセスログに記載されたURI - 2017年7月 0 500 1,000 1,500 2,000 2,500 0 5 10 15 20 25 30 35 40 2009 2010 2011 2012 2013 2014 2015 2016 2017 累 計 ア ク セ ス 数 万 月 間 ア ク セ ス 数 万 ITSアクセス数の経年変化 月平均 アクセス数累計 累計：2000万 月間：34万アクセス 調査日 2017/7
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜実績値 8年間の運用結果*を集計 61 統計要約 最小値 : 1 第１四分位点 : 73 中央値 : 193 平均値 : 396 第３四分位点 : 317 最大値 :24708230 ・1443万回の処理 ・半分が200ms以下 ・95%が1秒以下 ・中央値193ms * 8年分のProduction.logに記載された処理応答時間 (Redmine～DB) - 2017年7月 調査日 2017/7 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超
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜評価対象 8年間の運用結果*を集計し、主要画面を決定 62 ・2000万アクセス ・■チケット表示 ＋ ■チケット一覧で50% ・利用頻度、遅延 を体感しやすい画面 33% 17% 6% 5% 5% 4% 3% 3% 3% 2% 2% 2% 2% 1% 1% 11% 2000万アクセス ：ベンチマーク対象 チケット表示 チケット一覧 Wikiページ (Redmine_Draft) プロジェクトTop 検索（プロジェクト） 添付ダウンロード （Work_Time) ログイン画面 マイページ 添付画像サムネイル RedmineTop 時間入力 リポジトリ閲覧 チケット起票 その他 * 8年分のApache アクセスログに記載されたITSのURI - 2017年7月 調査日 2017/7
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜評価対象 8年間の運用結果*を集計し、主要画面を決定 63 ・2000万アクセス ・■チケット表示 ＋ ■チケット一覧で50% ・利用頻度、遅延 を体感しやすい画面 ・ベンチマーク対象が 全体の59.4%を網羅 33% 17% 5% 3% 2% 2000万アクセス ：ベンチマーク対象 チケット表示 チケット一覧 Wikiページ (Redmine_Draft) プロジェクトTop 検索（プロジェクト） 添付ダウンロード （Work_Time) ログイン画面 マイページ 添付画像サムネイル RedmineTop 時間入力 リポジトリ閲覧 チケット起票 その他 * 8年分のApache アクセスログに記載されたITSのURI - 2017年7月 調査日 2017/7
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜テストデータ* 64 規模 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万チケットを複写して製作 調査日 2017/7 200万チケットは ・3000万レコード ・14億9000万文字 カスタムフィールドは 77種に固定
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜テストデータ* 65 200万チケットの内訳 種類 件数 チケット数 200万 カスタムField値 1,200万 添付ファイル 140万 時間記録 74万 注記欄 363万 ウォッチャー数 76万 Ticket間 参照数 27万 記録文字数 14億9,000万 プロジェクト数 113 ユーザー数 457 * 実データ10万チケットを複写して製作 調査日 2017/7
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測方法 66 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 Ruby 2.3 Normal / OOBGC 3.3 / 3.4 Ruby 2.4 Normal 3.4 組合せ • OOBGC; Out Of Band Garbage Collection。Request処理中にRubyがGCを実行すると応答に遅延が生じる。 指定回数の処理毎に、間隙を縫ってGCを実行させることで応答の遅延を軽減する機能。 Passenger5.1 OS CentOS7 （64bit） Ruby 2.4 Rails4.2 Redmine 3.4 DBMS MySQL 5.6 （BP 8GB） HTTP Apache 2.4 Memory 16GBCPU 4cores VMware ESXi 6 【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
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測方法 67 ① 主要画面8種に対して2並列でそれぞれ10回アクセスし、これを5回繰返して計測。 ② 上記①を、下記3種のDBキャッシュ状態を順次切り替えて計測。 DBキャッシュ無 → DBキャッシュ保存･復元 → Fullメモリキャッシュ ③ 上記②のFullメモリキャッシュの計測値を平均した値を採用。 ④ 上記①～③を、下記要素の全組み合わせ環境で繰り返す。 Redmineバージョン、 Rubyバージョン、OOGBC有無、 10万～200万チケット、SSD/HDD 10万 20万 30万 50万 70万 100万 150万 200万 所要時間合計（ミリ秒） 679.7 677.2 810.1 839.9 816.3 865.4 845.4 866.1 Redmine3.4 Ruby2.4.1 MySQL5.6 BufferPool 8G SSD 主要画面７種のURI /its34 14.2 14.3 14.8 13.1 13 12.9 13 12.9 /its34/projects 6.6 6.9 6.6 6.4 6.3 6.3 6.3 6.4 /its34/login 31 31.1 29.7 30.4 29.2 30 29.2 29 /its34/projects/sscope 89.1 87.6 86.4 87.5 84.4 86.2 84.1 84.3 /its34/issues?per_page=200 224.5 217.5 227.2 231.1 215.6 230 216.2 215 /its34/issues/1 86.9 69.1 186.5 194.3 184.8 191.6 182 184.5 /its34/issues/47548 149.4 161.3 168.6 184.1 192.8 215.3 225.5 244 /its34/issues/51782 78 89.4 90.3 93 90.2 93.1 89.1 90 調査日 2017/7
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 2000 4000 6000 8000 10000 12000 Ruby2.0 nml Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.2 oobgc Ruby2.3 oobgc 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果１ 68 Redmine3.3の最速ベンチ ms 調査日 2017/7
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 2000 4000 6000 8000 10000 12000 Ruby2.0 nml Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.2 oobgc Ruby2.3 oobgc 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果１ 69 Redmine3.3の最速ベンチ ms 最も遅い Ruby2.0 に比して、 最も速い Ruby2.3+OOBGC は 32.1% 速い 調査日 2017/7
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果１ 70 Redmine3.4の最速ベンチ 0 2000 4000 6000 8000 10000 12000 Ruby2.0 nml Ruby2.3 oobgc Ruby2.2 oobgc Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.4 nml 10万 20万 30万 50万 70万 100万 150万 200万 ms 調査日 2017/7
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果１ 71 Redmine3.4の最速ベンチ 0 2000 4000 6000 8000 10000 12000 Ruby2.0_nml Ruby2.3_oobgc Ruby2.2_oobgc Ruby2.1_oobgc Ruby2.1_nml Ruby2.2_nml Ruby2.3_nml Ruby2.4_nml 10万 20万 30万 50万 70万 100万 150万 200万 ms 最も遅い Ruby2.0 に比して、 最も速い Ruby2.4 は 26.9% 速い 調査日 2017/7
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 Redmine 2.6 Redmine 3.0 Redmine 3.1 Redmine 3.2 Redmine 3.3 Redmine 3.4 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果２ 72 Redmine3.4は速いのか ms 調査日 2017/7
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 Redmine 2.6 Redmine 3.0 Redmine 3.1 Redmine 3.2 Redmine 3.3 Redmine 3.4 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果２ 73 Redmine3.4は速いのか ms ・性能向上（平均） 2.6 → 3.0 8.8% 2.6 → 3.1 5.6% 2.6 → 3.2 4.2% 2.6 → 3.3 3.5% 2.6 → 3.4 24.9% ・原因推測 ＋ Redmine3.4 ＋ Ruby2.4 － 機能増加 調査日 2017/7
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 Redmine 2.6 Redmine 3.0 Redmine 3.1 Redmine 3.2 Redmine 3.3 Redmine 3.4 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果２ 74 Redmine3.4は速いのか ms ・性能向上（平均） 2.6 → 3.0 8.8% 2.6 → 3.1 5.6% 2.6 → 3.2 4.2% 2.6 → 3.3 3.5% 2.6 → 3.4 24.9% ・原因推測 ＋ Redmine3.4 ＋ Ruby2.4 － 機能増加Redmine2.6から3.4へアップデートすると、 平均で24.9％の性能向上が得られる 調査日 2017/7
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.3 oobgc Ruby2.2 oobgc Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.4 nml Redmine 3.4 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果３ 75 Rubyバージョン変更の効果 Ruby2.0 nml Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.2 oobgc Ruby2.3 oobgc Redmine3.3 10万 20万 30万 50万 70万 100万 150万 200万 ms 調査日 2017/7
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.3 oobgc Ruby2.2 oobgc Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.4 nml Redmine 3.4 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果３ 76 Rubyバージョン変更の効果 Ruby2.0 nml Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.2 oobgc Ruby2.3 oobgc Redmine3.3 10万 20万 30万 50万 70万 100万 150万 200万 Redmine3.4 性能向上(平均) Ruby2.0→2.4 26.9% Ruby2.0→2.3OOBGC 24.5% Redmine3.3 性能向上(平均) Ruby2.0→2.3 31.2% Ruby2.0→2.3OOBGC 32.1% ms 調査日 2017/7
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.3 oobgc Ruby2.2 oobgc Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.4 nml Redmine 3.4 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果３ 77 Rubyバージョン変更の効果 Ruby2.0 nml Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.2 oobgc Ruby2.3 oobgc Redmine3.3 10万 20万 30万 50万 70万 100万 150万 200万 Redmine3.4 性能向上(平均) Ruby2.0→2.4 26.9% Ruby2.0→2.3OOBGC 24.5% Redmine3.3 性能向上(平均) Ruby2.0→2.3 31.2% Ruby2.0→2.3OOBGC 32.1% Redmine3.4において、Ruby2.0から2.4へ Updateすると平均26.9％の性能向上が得られる 調査日 2017/7 ms
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果３ 78 OOBGCの効果 78 Ruby2.0 nml Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.2 oobgc Ruby2.3 oobgc Redmine3.3 10万 20万 30万 50万 70万 100万 150万 200万 調査日 2017/7 0 2,000 4,000 6,000 8,000 10,000 12,000 Ruby2.0 nml Ruby2.3 oobgc Ruby2.2 oobgc Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.4 nml Redmine 3.4 10万 20万 30万 50万 70万 100万 150万 200万 ms
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果３ 79 OOBGCの効果 0 2,000 4,000 6,000 8,000 10,000 12,000 Ruby2.0 nml Ruby2.3 oobgc Ruby2.2 oobgc Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.4 nml Redmine 3.4 10万 20万 30万 50万 70万 100万 150万 200万 79 Ruby2.0 nml Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.2 oobgc Ruby2.3 oobgc Redmine3.3 10万 20万 30万 50万 70万 100万 150万 200万 Redmine3.3 性能向上(平均) OOBGC効果 Ruby2.2→2.2OOBGC 3.6% Redmine3.4 性能向上(平均) OOBGC効果 Ruby2.3→2.3OOBGC -7.1% 調査日 2017/7 ms
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ms ベンチマーク｜計測結果３ 80 OOBGCの効果 0 2,000 4,000 6,000 8,000 10,000 12,000 Ruby2.0 nml Ruby2.3 oobgc Ruby2.2 oobgc Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.4 nml Redmine 3.4 10万 20万 30万 50万 70万 100万 150万 200万 80 Ruby2.0 nml Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.2 oobgc Ruby2.3 oobgc Redmine3.3 10万 20万 30万 50万 70万 100万 150万 200万 Redmine3.3 性能向上(平均) OOBGC効果 Ruby2.2→2.2OOBGC 3.6% Redmine3.4 性能向上(平均) OOBGC効果 Ruby2.3→2.3OOBGC -7.1% Redmine3.3において、Ruby2.3にOOBGCを適用すると 平均 3.1％の性能向上が得られる Redmine3.4において、Ruby2.3にOOBGCを適用すると 平均 -7.1％の性能低下が生じる 調査日 2017/7
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ms ベンチマーク｜計測結果３ 81 OOBGCの効果 0 2,000 4,000 6,000 8,000 10,000 12,000 Ruby2.0 nml Ruby2.3 oobgc Ruby2.2 oobgc Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.4 nml Redmine 3.4 10万 20万 30万 50万 70万 100万 150万 200万 81 Ruby2.0 nml Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.2 oobgc Ruby2.3 oobgc Redmine3.3 10万 20万 30万 50万 70万 100万 150万 200万 Redmine3.3 性能向上(平均) OOBGC効果 Ruby2.2→2.2OOBGC 3.6% Redmine3.4 性能向上(平均) OOBGC効果 Ruby2.3→2.3OOBGC -7.1% Redmine3.3において、Ruby2.3にOOBGCを適用すると 平均 3.1％の性能向上が得られる Redmine3.4において、Ruby2.3にOOBGCを適用すると 平均 -7.1％の性能低下が生じる 調査日 2017/7 【事実】 今回の計測では、Redmine3.4ではOOBGCの効果が 出なくなった。 【推測】 本ベンチマークの処理条件においては、Redmine3.4 の内部処理変更によってオブジェクト生成と破棄が少 なくなり、5回に1度の高頻度なOOBGCは不要（処理 コスト＞メリット）になったのではないかと推測。 【知見】 Ruby2.3でRedmine3.4を動作させる場合は、利用条 件によってOOBGCが有効でない場合があるとわかっ た。 Redmine3.4は、Ruby2.4で動作させるのが最速。
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果４ 82 過去のRedmineと比較 Redmine自体は速くなった？遅くなった？ 調査日 2017/7
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 1,000 2,000 3,000 4,000 5,000 6,000 7,000 8,000 9,000 Redmine1.4 最 速 Redmine2.0 最 速 Redmine2.1 最 速 Redmine2.3 最 速 Redmine2.6 最 速 Redmine3.0 最 速 Redmine3.1 最 速 Redmine3.2 最 速 Redmine3.3 最 速 Redmine3.4 最 速 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果４ 83 過去のRedmineと比較 ms 調査日 2017/7
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 1,000 2,000 3,000 4,000 5,000 6,000 7,000 8,000 9,000 Redmine1.4 最 速 Redmine2.0 最 速 Redmine2.1 最 速 Redmine2.3 最 速 Redmine2.6 最 速 Redmine3.0 最 速 Redmine3.1 最 速 Redmine3.2 最 速 Redmine3.3 最 速 Redmine3.4 最 速 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果４ 84 過去のRedmineと比較 最速ベンチマークを 比較すると、 2.3 → 2.6 - 30% 2.3 → 3.4 - 5.9% 性能が低下してい る。 ms 調査日 2017/7
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 1,000 2,000 3,000 4,000 5,000 6,000 7,000 8,000 9,000 Redmine1.4 最 速 Redmine2.0 最 速 Redmine2.1 最 速 Redmine2.3 最 速 Redmine2.6 最 速 Redmine3.0 最 速 Redmine3.1 最 速 Redmine3.2 最 速 Redmine3.3 最 速 Redmine3.4 最 速 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果４ 85 過去のRedmineと比較 ms 性能変化の原因推測 ＋ Redmine内部改善 ＋ Ruby高速化 ＋ Multi Thread対応 ＋ Rails4.2の内部改善 － 機能増加 ※ Redmine2.3以前の計測は当時の 計算機とRuby1.8, 1.9, 2.0による もの。現在は電算機の能力が向上し ており比較精度は完全でない。よっ て参考値とする。 調査日 2017/7
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 1,000 2,000 3,000 4,000 5,000 6,000 7,000 8,000 9,000 Redmine1.4 最 速 Redmine2.0 最 速 Redmine2.1 最 速 Redmine2.3 最 速 Redmine2.6 最 速 Redmine3.0 最 速 Redmine3.1 最 速 Redmine3.2 最 速 Redmine3.3 最 速 Redmine3.4 最 速 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果４ 86 過去のRedmineと比較 ms 機能増加 Redmine 2.3, 2.4, 2.5, 2.6, 3.0, 3.1, 3.2, 3.3, 3,4 Spent time 2013-03 ～ 2017-07 Includes 306 Features implemented 495 Patches applied 561 Defects fixed Still very fast and reliable! 調査日 2017/7
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 1,000 2,000 3,000 4,000 5,000 6,000 7,000 8,000 9,000 Redmine1.4 最 速 Redmine2.0 最 速 Redmine2.1 最 速 Redmine2.3 最 速 Redmine2.6 最 速 Redmine3.0 最 速 Redmine3.1 最 速 Redmine3.2 最 速 Redmine3.3 最 速 Redmine3.4 最 速 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果４ 87 過去のRedmineと比較 ms 機能増加 Redmine 2.3, 2.4, 2.5, 2.6, 3.0, 3.1, 3.2, 3.3, 3,4 Spent time 2013-03 ～ 2017-07 Includes 192 Features 294 Patches 406 Defects repaired Still so fast and reliable! ・Redmine2.3を3.4へUpdateすると5.9%性能が 低下する ・多くの有益な機能が追加されている。 コア開発チームの努力と技術の進歩により、 応答性能の低下は最小限にとどまった。 調査日 2017/7
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜小まとめ 88 Redmine3.4の性能が大幅に改善した主な理由 理由1：Ruby2.3, 2.4の処理性能向上 Ex. Towards Faster Ruby Hash Tables Vladimir Makarov 理由2：Redmine core パフォーマンス改善11種 Issue# Subject 25022 Add an index on attachments.disk_filename 24865 Load associations of query results more efficiently 24839 Minor performance improvement - Replace count by exists? 24787 Don't preload all filter values when displaying issues/time entries 24587 Improve custom fields list performance 24433 The changeset display is slow when changeset_issues has very many records 23987 Add an index on issues.parent_id 23743 Add index to workflows.tracker_id 23519 Don't preload projects and roles on Principal#memberships association 22850 Speedup remove_inherited_roles 21608 Project#allowed_to_condition performance
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果5 89 今回のベンチマークはSSD主体で行った。 HDDとSSDの性能差はどの程度か？
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 2000 4000 6000 8000 10000 12000 Redmine2.3 HDD Redmine2.6 HDD Redmine3.4 HDD Redmine3.4 SSD 10万 20万 30万 50万 70万 100万 150万 200万 ms ベンチマーク｜計測結果５ 90 HDDをSSDに置換する効果 調査日 2017/7
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 2000 4000 6000 8000 10000 12000 Redmine2.3 HDD Redmine2.6 HDD Redmine3.4 HDD Redmine3.4 SSD 10万 20万 30万 50万 70万 100万 150万 200万 ms ベンチマーク｜計測結果５ 91 HDDをSSDに置換する効果 Redmine3.4 HDD → SSD 平均18.6%の性能向上 【参考】2015年5月の調査 平均25.7%の性能向上 （今回の調査でSSDの性能を生 かし切れていない可能性） 調査日 2017/7
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 2000 4000 6000 8000 10000 12000 Redmine2.3 HDD Redmine2.6 HDD Redmine3.4 HDD Redmine3.4 SSD 10万 20万 30万 50万 70万 100万 150万 200万 ms ベンチマーク｜計測結果５ 92 HDDをSSDに置換する効果 【参考】2015年5月の調査 平均25.7%の性能向上 （今回の調査でSSDの性能を生 かし切れていない可能性） HDDをSSDに交換すると、環境によって 平均18.6％～25.7％の性能向上が得られる Redmine3.4 HDD → SSD 平均18.6%の性能向上 調査日 2017/7
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果６ 93 複数プラグイン導入の性能への影響 Redmineの性能に、プラグインがどの程度 の影響を与えるのか？
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果６ 94 複数プラグイン導入の性能への影響 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
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果６ 95 複数プラグイン導入の性能への影響 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
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果７ 96 FTS* 応答性能の計測 * FTS; Full Text Search 全文検索（索引型／非索引型） Redmineの全文検索性能は改善されたのか？ FullTextSearchプラグインの導入によって、 どの程度の高速化されるのか？
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 2,000 4,000 6,000 8,000 10,000 12,000 14,000 No Cash BP Save & Load Full Cash No Cash BP Save & Load Full Cash No Cash BP Save & Load Full Cash Redmine3.0 非索引型 Redmine3.3 非索引型 Redmine3.3 索引型 全 文 検 索 所 用 時 間 積 算 （ 秒 ） 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果７ 97 FTS* 応答性能の計測 秒 調査日 2017/7 * FTS; Full Text Search 全文検索（索引型／非索引型） * BP; データベースのBuffer Pool メモリ。一度読込んだらメモリ上に貯蔵してDisk I/Oを削減 非索引型 索引型 Redmineの全文検索処理 ・非索引型 ・索引型（プラグイン導入） Redmine Full Text Search V0.4.0
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 2,000 4,000 6,000 8,000 10,000 12,000 14,000 No Cash BP Save & Load Full Cash No Cash BP Save & Load Full Cash No Cash BP Save & Load Full Cash Redmine3.0 非索引型 Redmine3.3 非索引型 Redmine3.3 索引型 全 文 検 索 所 用 時 間 積 算 （ 秒 ） 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果７ 98 FTS* 応答性能の計測 秒 調査日 2017/7 * FTS; Full Text Search 全文検索（索引型／非索引型） * BP; データベースのBuffer Pool メモリ。一度読込んだらメモリ上に貯蔵してDisk I/Oを削減 非索引型 索引型 Redmineの全文検索処理 ・非索引型 ・索引型（プラグイン導入） Redmine Full Text Search V0.4.0 計測時のDBキャッシュ状態３種 ・No Cash ・BP* Save & Load（実用検索） ・Full Cashed 計測対象 1) /its33/search?q=ATO 2) /its33/search?q=WIP 3) /its33/search?q=sSCOPE ※ 実行条件、回数等は共通
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved * FTS; Full Text Search 全文検索（索引型／非索引型） * BP; データベースのBuffer Pool メモリ。一度読込んだらメモリ上に貯蔵してDisk I/Oを削減 0 2,000 4,000 6,000 8,000 10,000 12,000 14,000 No Cash BP Save & Load Full Cash No Cash BP Save & Load Full Cash No Cash BP Save & Load Full Cash Redmine3.0 非索引型 Redmine3.3 非索引型 Redmine3.3 索引型 全 文 検 索 所 用 時 間 積 算 （ 秒 ） 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果７ 99 FTS* 応答性能の計測 秒 調査日 2017/7 Redmine3.0の全文検索処理 【非索引型】 ・No Cash： 12,193秒 10万チケット 24秒 100万チケット 207秒 200万チケット 6204秒 ・BP Save & Load： 9,415秒 10万チケット 17秒 100万チケット 162秒 200万チケット 3601秒 ・Full Cashed： 13秒 10万チケット 0.3秒 100万チケット 2.2秒 200万チケット 2.7秒 非索引型 索引型
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved * FTS; Full Text Search 全文検索（索引型／非索引型） * BP; データベースのBuffer Pool メモリ。一度読込んだらメモリ上に貯蔵してDisk I/Oを削減 0 2,000 4,000 6,000 8,000 10,000 12,000 14,000 No Cash BP Save & Load Full Cash No Cash BP Save & Load Full Cash No Cash BP Save & Load Full Cash Redmine3.0 非索引型 Redmine3.3 非索引型 Redmine3.3 索引型 全 文 検 索 所 用 時 間 積 算 （ 秒 ） 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果７ 100 FTS* 応答性能の計測 調査日 2017/7 秒 非索引型 索引型 Redmine3.3の全文検索処理 【非索引型】 ・No Cash： 555秒 10万チケット 2秒 100万チケット 12秒 200万チケット 295秒 ・BP* Save & Load： 421秒 10万チケット 1秒 100万チケット 12秒 200万チケット 222秒 ・Full Cashed： 26秒 10万チケット 0.5秒 100万チケット 5秒 200万チケット 8秒
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果７ 101 FTS 応答性能の計測 調査日 2017/7 Redmine3.3の全文検索処理 【非索引型】 ・No Cash： 555秒 10万チケット 2秒 100万チケット 12秒 200万チケット 295秒 ・BP Save & Load： 421秒 10万チケット 1秒 100万チケット 12秒 200万チケット 222秒 ・Full Cashed： 26秒 10万チケット 0.5秒 100万チケット 5秒 200万チケット 8秒 0 100 200 300 400 500 600 No Cash BP Save & Load Full Cash No Cash BP Save & Load Full Cash Redmine3.3 非索引型 Redmine3.3 索引型 検 索 所 用 時 間 積 算 （ 秒 ） 10万 20万 30万 50万 70万 100万 150万 200万 秒 非索引型 索引型
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 100 200 300 400 500 600 No Cash BP Save & Load Full Cash No Cash BP Save & Load Full Cash Redmine3.3 非索引型 Redmine3.3 索引型 検 索 所 用 時 間 積 算 （ 秒 ） 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果７ 102 FTS 応答性能の計測 調査日 2017/7 非索引型 索引型 Redmine3.3の全文検索処理 【索引型】 ・No Cash： 25秒 10万チケット 0.5秒 100万チケット 4秒 200万チケット 8秒 ・BP Save & Load： 19秒 10万チケット 0.4秒 100万チケット 3秒 200万チケット 6秒 （実用検索） ・Full Cashed： 16秒 10万チケット 0.4秒 100万チケット 2秒 200万チケット 5秒 秒
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 23.5 39.6 61.4 100.4 143.2 206.9 5,415.2 6,203.4 1,524 BP Save & Load 17.1 32.5 52.7 80.6 112.6 162.6 5,355.9 3,601.6 1,177 Full Cash 0.4 0.6 0.8 1.2 1.6 2.3 2.7 3.3 2 Redmine 3.3 非索引型 No Index No Cash 1.6 3.0 4.6 7.5 8.1 11.9 224.0 295.7 70 BP Save & Load 1.1 1.9 2.9 4.7 8.0 11.8 169.4 222.0 53 Full Cash 0.5 0.9 1.2 2.1 2.9 4.5 6.1 8.3 3 Redmine 3.3 索引型 FTS Indices No Cash 0.5 0.9 1.2 2.0 2.7 3.8 6.0 8.0 3 BP Save & Load 0.4 0.7 0.9 1.5 2.1 2.9 4.5 6.0 2 Full Cash 0.4 0.6 0.8 1.2 1.7 2.4 3.8 4.9 2 ベンチマーク｜計測結果７ 103 FTS 応答性能の計測 調査日 2017/7 全文検索 所用時間（秒 sec）
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 23.5 39.6 61.4 100.4 143.2 206.9 5,415.2 6,203.4 1,524 BP Save & Load 17.1 32.5 52.7 80.6 112.6 162.6 5,355.9 3,601.6 1,177 Full Cash 0.4 0.6 0.8 1.2 1.6 2.3 2.7 3.3 2 Redmine 3.3 非索引型 No Index No Cash 1.6 3.0 4.6 7.5 8.1 11.9 224.0 295.7 70 BP Save & Load 1.1 1.9 2.9 4.7 8.0 11.8 169.4 222.0 53 Full Cash 0.5 0.9 1.2 2.1 2.9 4.5 6.1 8.3 3 Redmine 3.3 索引型 FTS Indices No Cash 0.5 0.9 1.2 2.0 2.7 3.8 6.0 8.0 3 BP Save & Load 0.4 0.7 0.9 1.5 2.1 2.9 4.5 6.0 2 Full Cash 0.4 0.6 0.8 1.2 1.7 2.4 3.8 4.9 2 ベンチマーク｜計測結果７ 104 FTS 応答性能の計測 調査日 2017/7 全文検索 所用時間（秒 sec） 非索引型の全文検索は10～20万チケットで性能限界に到達する。
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 23.5 39.6 61.4 100.4 143.2 206.9 5,415.2 6,203.4 1,524 BP Save & Load 17.1 32.5 52.7 80.6 112.6 162.6 5,355.9 3,601.6 1,177 Full Cash 0.4 0.6 0.8 1.2 1.6 2.3 2.7 3.3 2 Redmine 3.3 非索引型 No Index No Cash 1.6 3.0 4.6 7.5 8.1 11.9 224.0 295.7 70 BP Save & Load 1.1 1.9 2.9 4.7 8.0 11.8 169.4 222.0 53 Full Cash 0.5 0.9 1.2 2.1 2.9 4.5 6.1 8.3 3 Redmine 3.3 索引型 FTS Indices No Cash 0.5 0.9 1.2 2.0 2.7 3.8 6.0 8.0 3 BP Save & Load 0.4 0.7 0.9 1.5 2.1 2.9 4.5 6.0 2 Full Cash 0.4 0.6 0.8 1.2 1.7 2.4 3.8 4.9 2 ベンチマーク｜計測結果７ 105 FTS 応答性能の計測 調査日 2017/7 全文検索 所用時間（秒 sec） 非索引型の全文検索は10～20万チケットで性能限界に到達する。 Redmine3.3に索引型の全文検索Pluginを導入すると、実用的な検索 速度は3.0に比べて平均で約490倍速くなり、
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 23.5 39.6 61.4 100.4 143.2 206.9 5,415.2 6,203.4 1,524 BP Save & Load 17.1 32.5 52.7 80.6 112.6 162.6 5,355.9 3,601.6 1,177 Full Cash 0.4 0.6 0.8 1.2 1.6 2.3 2.7 3.3 2 Redmine 3.3 非索引型 No Index No Cash 1.6 3.0 4.6 7.5 8.1 11.9 224.0 295.7 70 BP Save & Load 1.1 1.9 2.9 4.7 8.0 11.8 169.4 222.0 53 Full Cash 0.5 0.9 1.2 2.1 2.9 4.5 6.1 8.3 3 Redmine 3.3 索引型 FTS Indices No Cash 0.5 0.9 1.2 2.0 2.7 3.8 6.0 8.0 3 BP Save & Load 0.4 0.7 0.9 1.5 2.1 2.9 4.5 6.0 2 Full Cash 0.4 0.6 0.8 1.2 1.7 2.4 3.8 4.9 2 ベンチマーク｜計測結果７ 106 FTS 応答性能の計測 調査日 2017/7 全文検索 所用時間（秒 sec） 非索引型の全文検索は10～20万チケットで性能限界に到達する。 Redmine3.3に索引型の全文検索Pluginを導入すると、実用的な検索 速度は3.0に比べて平均で約490倍速くなり、10万チケットを平均0.4 秒、200万チケット（≒15億文字）を平均6秒で検索可能になる。 2 million tickets include approximately 1.5 billion multibyte characters. Indexed FTS takes 6 sec.
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果８ 107 Redmine3.4は200万チケットでも “サクサク”なのか？ 0 100 200 300 400 500 600 700 800 900 1000 10万 20万 30万 50万 70万 100万 150万 200万 チケット表示（小） チケット表示（大） チケット表示（中） チケット一覧 プロジェクトTop プロジェクト一覧 ログイン画面 Redmine Top ms 調査日 2017/7
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果８ 108 Redmine3.4は200万チケットでも “サクサク”なのか？ 0 100 200 300 400 500 600 700 800 900 1000 10万 20万 30万 50万 70万 100万 150万 200万 チケット表示（小） チケット表示（大） チケット表示（中） チケット一覧 プロジェクトTop プロジェクト一覧 ログイン画面 Redmine Top ms チューニングの結果、Redmine3.4の 主要画面8種の平均応答時間は100ms 調査日 2017/7
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果８ 109 Redmine3.4は200万チケットでも “サクサク”なのか？ 0 100 200 300 400 500 600 700 800 900 1000 10万 20万 30万 50万 70万 100万 150万 200万 チケット表示（小） チケット表示（大） チケット表示（中） チケット一覧 プロジェクトTop プロジェクト一覧 ログイン画面 Redmine Top ms ①全文検索 20秒 Full_Text_Search Plugin ②DB始動時の暖機運転5分 MySQL5.6, Postgres9.4に対策有り (BufferPool dump/Restore) 調査日 2017/7 ③BufferPool 8GB以上必須
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果８ 110 Redmine3.4は200万チケットでも “サクサク”なのか？ 0 100 200 300 400 500 600 700 800 900 1000 10万 20万 30万 50万 70万 100万 150万 200万 チケット表示（小） チケット表示（大） チケット表示（中） チケット一覧 プロジェクトTop プロジェクト一覧 ログイン画面 Redmine Top ms 調査日 2017/7 ③BufferPool 8GB以上必須 ①全文検索 20秒 Full_Text_Search Plugin ②DB始動時の暖機運転5分 MySQL5.6, Postgres9.4に対策有り (BufferPool dump/Restore) 3点対策して環境を整備すれば 200万チケットまで大丈夫
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次 111 第１部 背景と要求 第２部 チューニングの基本 第３部 ベンチマーク 第４部 性能改善事例集 第５部 まとめ 第６部 付録 111
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次 112 第１部 背景と要求 第２部 チューニングの基本 第３部 ベンチマーク 第４部 性能改善事例集 第５部 まとめ 第６部 付録 112
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 性能改善事例集 113 1. 8年間に渡るRedmineの運用におい て、どのような問題が発生し、どう やって解消したのか 2. 信頼性と安定性を維持する取組みの 「実際と限界」に焦点 3. 各種設定、チューニング方法、性能計 測方法を全て紹介する
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 計測 - 定量化手法 ｢測定できないものは制御できない｣* １．テスト実行時間 （Redmine Built-in Test Code） ２．負荷ベンチマーク ・httpref http://www.hpl.hp.com/research/linux/httperf/ ・wrk https://github.com/wg/wrk ・apache bench http://httpd.apache.org/docs/2.2/programs/ab.html ３．時間計測 ・MySQL Slow-query ログ ・Redmineログ （Production.log, Development.log） ４．分析 ・SQL実行計画（MySQL Workbench） https://www-jp.mysql.com/products/workbench/ ・Chrome開発者ツール https://developer.chrome.com/devtools ・ネットワークスループット調査 iperf https://iperf.fr/ (Win版は× : ブルースクリーン死亡） 114* DeMarco, Tom., 1982, “You can’t control what you can't measure.”
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングチェックリスト20 １／２ 115 １）Memory搭載・設定 DBMSに十分なキャッシュメモリを付与 ２）Disk I/O HDD→ SSD ３）CPUコア数と同時並行処理数 ４）OS選択 Linux ／ 起動プロセスとパッケージは必要最低限に削ぎ落とす。 ５）DBMS選択 MySQL, Postgresql を使用して、必ず設定値を変更。 ６）通信データ圧縮 Apache等 HTTP/1.1 Compression ７）Rubyバージョン利用可能な最新版を使用 1.9 < 2.0 < < < 2.1 < 2.2 < 2.3 << 2.4 ８）Webアプリケーションサーバー選択 WEBrick < < < Thin < < Passenger4 ≒ Passenger5 ９）通信経路の狭帯域対策 10M/bps → 1G/bps (ケーブル交換、装置交換) 同一サーバーに置くことで通信帯域を広くする。Local Loopback は最速のNIC １０）通信装置の性能向上 Normal-HubをSwitching-Hubへ交換しコリジョンによる通信効率低下を回避 １１）Subversionリポジトリの同期トリガを変更
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 116 １２）Subversionリポジトリの同期対象を指定する １３）Subversionセッションキャッシュを付与する １４）Subversion通信圧縮機能を利用する １５）MySQLメモリチューニング メモリを十分に付与し、全インデックスや全データをできるだけオンメモリ化 １６）カスタムフィールドの設定 「検索対象」の数が多いと極端に性能が落ちる １７）DBMSサーバーの「暖機運転」 MySQL 5.6： Buffer-Pool Save & Load PostgreSQL 9.4： pg_prewarm １８）メール非同期送信（Async） １９）Plugin導入数 ２0）RubyとGC ・内部処理の大幅改善によりRuby2.4が最速のバージョン ・2位は Ruby2.3＋OOBGC（調査時点 2017/07 ） チューニングチェックリスト20 １／２
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例１）【性能】全体がひどく遅い 117 【チューニング要素】 ・H/W: HDD, Memory, CPU ・S/W: OS, DBMS, Http Server, Ruby, WebAppServer ・N/W: 通信帯域, Switching-Hub １）Memory搭載・設定 DBMSに十分なキャッシュメモリを付与 ２）Disk I/O HDD→ SSD OS, DBMS, APL（Redmine他）はSSDに格納し、他のデータはHDDへ ３）CPUコア数と同時並行処理数 処理要求が集中した時の待ち行列 CPUコアやHTスレッド数に合わせて並行度を上げ、最大待ち時間を低く抑える。 - Passenger：自動調整 （指定可能） - Unicorn , Thin：起動サーバー数を増減
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例１）【性能】全体がひどく遅い 118 【チューニング要素】 ・H/W: HDD, Memory, CPU ・S/W: OS, DBMS, Http Server, Ruby, WebAppServer ・N/W: 通信帯域, Switching-Hub ４）OS選択 Windows Bitnamiは５万件まで（制約：Ruby2.0系, DBMS 32bit） 最新のBitnami 3.3、3.4系はRuby2.3に。未調査だが期待。（制約：DBMS 32bit） 10万件扱うなら、Windows スクラッチ構築 15万件以上扱うなら200万件まで確認したLinux 64bitを推奨 ５）DBMS選択 MySQL, Postgresql を使用して、必ず設定値を変更。Sqliteは１万チケットまで ６）通信データ圧縮 Apache等 HTTP/1.1 Compression ネットワーク帯域が狭い時、通信輻輳時に高い効果
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例１）【性能】全体がひどく遅い 119 【チューニング要素】 ・H/W: HDD, Memory, CPU ・S/W: OS, DBMS, Http Server, Ruby, WebAppServer ・N/W: 通信帯域, Switching-Hub ７）Rubyバージョン 利用可能な最新版を使用 1.9 < 2.0 < < < 2.1 < 2.2 < 2.3 << 2.4 ８）Webアプリケーションサーバー選択 WEBrick < < < Thin < < Passenger4 ≒ Passenger5 （Unicornは未調査。速いがPassengerに比して扱い難い。上級者向け） ９）通信経路の狭帯域対策 10M/bps → 1G/bps (ケーブル＋Switch機器を交換) Local Loopback は最速のNIC １０）通信装置の性能向上 Normal-HubをSwitchへ交換しコリジョンによる通信効率低下を回避
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例２）【性能】リポジトリタブが遅い 120 【チューニング要素】 ・H/W: HDD, Memory, CPU ・S/W: DBMS, Ruby, WebAppServer, Subversion Server ・N/W: 通信帯域, Switching-Hub １）Subversionリポジトリの同期トリガを変更 SubversionとRedmine間のリポジトリ同期は、画面上のリポジトリタブをクリッ クすると実施されるのが既定の動作。リビジョン数が増えてくると表示されるまで に１分以上待たされる。 Redmine全体管理画面の「コミットを自動取得する」をOFFにして、Subversion リポジトリ側のPost-Commit-Hookに同期スクリプトを組み込むことで、同期ト リガが“コミット時”へ変更され、画面上のリポジトリタブは直ちに表示されるよう になる。 ２）Subversionリポジトリの同期対象を指定する 前述のPost-Commit-Hookは全プロジェクトを対象にするため、リポジトリ数が多 い場合5分以上かかる場合がある。ほぼ同時に5人が5回ずつコミットすると同期が 25並列で実行されてしまい、処理輻輳によりRedmineが応答しなくなる。 特定のProjectのみ同期を実施するよう、スクリプトに追記する。
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例２）【性能】リポジトリタブが遅い 121 【チューニング要素】 ・H/W: HDD, Memory, CPU ・S/W: DBMS, Ruby, WebAppServer, Subversion Server ・N/W: 通信帯域, Switching-Hub ３）Subversionセッションキャッシュ セッション毎にキャッシュメモリを付与 （Subversion 1.7 以上） ４）Subversion通信圧縮機能 通信内容の圧縮レベル指定（Subversion 1.7 以上） ５）同一サーバーに置き、通信帯域を広くする Local loopback, TCP/UDP/Socket通信は高速 ６）MySQL テーブル更新が遅い DBMSメモリ設定 SSD採用
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例３）【性能】検索が遅い 122 １）MySQLメモリチューニング ・メモリをできるだけ積み込む ・全インデックス、全データをオンメモリにする ２）カスタムフィールドの設定 「検索対象」の数が多いと極端に性能が落ちる 【チューニング要素】 ・H/W: Memory, CPU ・S/W: DBMS, Redmine
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例４）【性能】画面応答が遅い 123 １）Rubyのバージョン 処理性能 1.9 < 2.0 < < < 2.1 < 2.2 < 2.3 << 2.4 ２）MySQLメモリチューニング 全インデックスと主要データをメモリに乗せる ３）初回アクセスが極端に遅い MySQL 5.6 – Bufferpool save and load PostgreSQL 9.4 - pg_prewarm ４）CPUコア数と同時並行処理数 処理要求が集中した時の待ち行列 CPUコアやHTスレッド数に合わせて並行度を上げ、最大待ち時間を低く抑える - Passenger：自動調整 （指定も可能） - Thin：起動サーバー数を増減 【チューニング要素】 ・H/W: HDD, Memory, CPU ・S/W: OS, DBMS, Http Server, Ruby, WebAppServer ・N/W: 通信帯域, Switching-Hub
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例４）【性能】画面応答が遅い 124 ５）メール非同期送信（Async） 通知先が多い ／ メールサーバー（MTA）が遅い ６）Plugin導入数 導入数が多いと遅くなる。 大量データの応答性能まで考慮されているPluginはそう多くない。 ７）通信データの圧縮 HTTP1.1/Compression （最大10倍速） 【チューニング要素】 ・H/W: HDD, Memory, CPU ・S/W: OS, DBMS, Http Server, Ruby, WebAppServer ・N/W: 通信帯域, Switching-Hub
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例５）【性能】特定プラグインが遅い 125 【チューニング要素】 ・H/W: Memory, CPU ・S/W: DBMS, Ruby, WebAppServer - 多くのプラグインは大量のデータ処理を想定していない。 極端に遅い場合はチューニングを施し、作者にパッチを送付できる。 処理遅延の原因は、SQL／コード実装／データ設計の３系統に大別できる。 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 ・アプリコード調査手順（今回は実施せず） ・データ設計調査手順 （今回は実施せず）
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例６）【信頼性】不安定で手間がかかる 126 １）3歩遅れの「枯れた技術」 末尾が3になったら導入 例）Redmine 3.4.3 ２）Windows <<< Linux OS 両方面倒を見てきたが、Ruby, Rails はWindowsで制限が多い（印象） ３）RedmineUpdateの工夫 新旧の環境を並立させて動作を確認し、準備が整ったら切り替える ４）OSS パッチの取込み （Redmineに限って言えば）性能が改善され、問題は解消している。 Gitの追跡ブランチモードで git cloneしてLocal変更との共存を確保しつつ、 git pull だけでパッチを取りこめる。 例）mkdir /var/lib/its/rm34_its cd /var/lib/its/rm34_its git clone https://github.com/redmine/redmine.git . git checkout -b 3.4-stable-local origin/3.4-stable 【チューニング要素】 ・H/W: Memory, CPU ・S/W: DBMS, Ruby, WebAppServer
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例６）【信頼性】不安定で手間がかかる 127 ５）Exception発生をMail 通知し、不具合を確実に検出 Redmine本体のExceptionは8年間でもほんの僅か ６）Redmine本体やRailsに手を入れない Redmine本体の品質は極めて高い テストコードのカバレッジ率がとても高い http://www.redmine.org/builds/coverage/ ７）Pluginは魅力的だが、あまり採用していない Redmine本体のUpdateの足枷になる テストコードが無く、DBテーブル構造を壊す例もある 【参考】 MTBF 8,820時間、MTTR 17時間、稼働率 99.8% 【チューニング要素】 ・H/W: Memory, CPU ・S/W: DBMS, Ruby, WebAppServer
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例６）【信頼性】不安定で手間がかかる 128 ８）完全なクローン環境を常設 ・ゴミデータ、評価用データを本番に持ち込ませない ・要望を受けてから手動で同期 ・誤入力の事故を防止するため、画面の色を変えている 【チューニング要素】 ・H/W: Memory, CPU ・S/W: DBMS, Ruby, WebAppServer Dump and Restore
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved Munin: Average latencyMunin: Average latency 事例７）【性能】電算機のH/W資源不足 129 １）1VMに集約し、狭帯域通信を回避 ２）CPU キャッシュの大きなものを複数コア用意 同時接続の処理数に合わせる ３）メモリ できるだけ積み込む ４）SSD導入： SSD（OS, DBMS, Redmine）、HDD（その他データ） ↓ SSD切替点↓ SSD切替点 【HDD】突出ピークが無くなった。【SSD】ピークが無くなりI/O waitが小さくなった。 振れ幅が小さく、余力が見てとれる。
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例８）【性能】電算機通信網の帯域不足 130 ＜Network＞ １）主要通信経路は1G/bpsに統一 10M/bps, 100M/bps のボトルネックを排除 ２）Normal Hub → Switching Hub コリジョン発生率の低減 ３）Local Loopback通信 サーバー統合による通信の高速化
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例９）【性能】起動が遅い 131 ＜DBMSの起動・再起動直後、初回アクセスだけが極端に遅い＞ １）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
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 設定例１）基本S/W 132 OS, File-System １）OS CentOS 6 / 7 プロセス、パッケージは必要最低限に削ぎ落とす。 （パッチ適用、最少の停止頻度、セキュリティー、メモリ） ２）File-System Ext4 nobarrier チューン http://goo.gl/LYwfA0 ３）Kernel設定 ・[SSD] Disk I/O スケジューラーを cfq から deadline へ変更 ・[SSD] SWAP抑制 vm.swappiness=1 ※ 性能への影響は未確認
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 設定例２）ミドルウェア 133 DBMS, WebServer, Web Application Server ＜DBMS＞ １）チューニング設定 ・MySQL 5.6 ２）SSDによるI/O改善 ・DBMS設定 MySQL innodb_flush_neighbors = 0 ・配置構成 DBデータだけでなく、OS全体をSSDに乗せると効果大 ・結果例 200万チケット分のDBデータをダンプ/リストア HDD → SSDにより33％向上（5分早く終わる）
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 設定例２）ミドルウェア 134 DBMS, WebServer, Web Application Server ＜WebServer＞ ３）通信圧縮 Compress, Gzip, Deflate 圧縮 ＜Web Application Server＞ ４）選択 WEBLick は性能 × 運用の容易さは Unicorn < Passenger ５）Phusion Passenger 4 → 5 で 0.6％向上（計測の誤差範囲） ６）Passenger と OOBGC Passenger4, Ruby2.1, OOBGC(gctools)で安定稼働（実績１年） Passenger5, Ruby2.2, OOBGC(gctools)で安定稼働（実績6ヶ月） Passenger5, Ruby2.3, OOBGC(gctools)で安定稼働（実績１年） ７）Passenger Enterprise Multi Threadモードで○○％ 向上 (未調査) 利用料金は 5000円／月程度
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 設定例３）応用S/W 135 Ruby, OOBGC, Redmine, Subversion ＜Ruby＞ ・GCの大幅改善によりRuby2.4が最速のバージョン ・2位は Ruby2.3＋OOBGC（調査時点 2017/07 ） ＜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.3, 2.4（Normal）が総合的に見て最適選択。 OOBGC有は最大性能への向上を必要とする方向け（ちょいムズ）
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 設定例３）応用S/W 136 Ruby, OOBGC, Redmine, Subversion ＜Redmine＞ ・カスタムフィールドの設定値「検索条件」の数を減らす。 例「14万チケットだと30種 ○○秒 → 5種 〇秒」 （未計測だが効果は絶大） ・メール非同期送信(Async) config/configuration.yml production: email_delivery: delivery_method: :async_smtp async_smtp_settings:
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 設定例３）応用S/W 137 Ruby, OOBGC, Redmine, Subversion ＜VCS＞ ・Subversion Server 1.7以降のセッションキャッシュ付与機能 セッションキャッシュにより、通信応答速度が向上する。 ・Subversion Server 1.7以降の通信圧縮機能 セッションデータ通信内容の多くはテキストデータ。 高い圧縮によって通信効率と応答性が向上する。
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次 138 第１部 背景と要求 第２部 チューニングの基本 第３部 ベンチマーク 第４部 性能改善事例集 第５部 まとめ 第６部 付録 138
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次 139 第１部 背景と要求 第２部 チューニングの基本 第３部 ベンチマーク 第４部 性能改善事例集 第５部 まとめ 第６部 付録 139
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved お話ししたこと 140 １）200万チケットでもサクサク動くRedmineの全レシピ* ２）Redmine2.6 を 3.4 へUpdateすると平均で24.9％速くなる ３）Ruby2.0 を 2.4 へUpdateすると平均で26.9％速くなる ４）HDDをSSDに変更すると平均で18. 5％～25. 7％速くなる ５）非索引型の全文検索は10万チケットで性能限界に到達するが、 FTS-Pluginの導入によって約490倍速くなり、 200万チケットの環境で平均0.4～6秒で全文検索できる ６） Redmineチューニング事例 9種 *全レシピ： 設定値の一括ダウンロードはこちら (GitHub Gist) Download: Setting_paramaters_for_Redmine_Performance_Tuning.txt https://gist.github.com/akahane92/771f9a52d81af9864dd8
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved まとめ｜実際 141 ・初期値のままでは、1万チケットまで ・最低限のチューニングで、5万チケットまで（Windows Bitnami） ・最低限のチューニングで、10万チケットまで（Linux,MySQL,Windowsスクラッチ） ・ある程度のチューニングで、200万チケットまで（Linux,MySQL） ・最大限のチューニング （必要としてないので今はやっていない） 処理並行度を上げる、高IOPsのDisk採用、DBMSのI/O最適化 例）Linux, MySQL： Nginx + Unicorn ロードバランサ ＋ WebAppServerクラスタリング ＋ DBMSクラスタリングと、R/W、R/Oの分離、SSD PCIe
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved まとめ｜限界 143 RedmineのFTS (非索引型) （Redmineは悪くないが）10万チケットを超えた時点で検索が遅くなる。例 えばCPU４コアで稼働している時に、全プロジェクト横断の検索が４回ク リックされ、並行で実行されるとCPUが占有されてRedmineが無応答になっ てしまう。 → 今回、 Full Text Search Plugin による対処策が得られた。 十分な性能を確認できたことから、検索に関する懸念要素が払拭さ れた。 数十億文字を記録・蓄積している。何らかの索引型FTSをRedmine コアに標準機能として組み込んで欲しい。 検索できなくて困っているのは添付ファイル。先頃、良策がPlanioさ んから提供された。とても期待している。 ( Feature #306 Full Text Search of files )
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次 144 第１部 背景と要求 第２部 チューニングの基本 第３部 ベンチマーク 第４部 性能改善事例集 第５部 まとめ 第６部 付録 144
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次 145 第１部 背景と要求 第２部 チューニングの基本 第３部 ベンチマーク 第４部 性能改善事例集 第５部 まとめ 第６部 付録 145
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録｜性能関連設定の一覧 146 本稿で扱った性能ベンチ－マークは下記設定による。 1. 計測プログラム 2. Apache2.2, 2.4 HTTP/1.1 通信圧縮 3. Passenger 4. MySQL 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
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録｜計測方法 147 計測プログラム # bench.rb # -*- coding: utf-8 -*- url_list = [ "/its34 ", "/its34/projects ", "/its34/login ", "/its34/projects/sscope ", "/its34/issues?per_page=200 ", "/its34/issues/1 ", "/its34/issues/47548 ", "/its34/issues/51782 " ] puts "--- Environment ---" puts `httpd -version` puts `ruby -v` puts `gem list --local passenger` puts `export RAILS_ENV=production; /var/lib/its/rm32_its/bin/about` puts `export RAILS_ENV=production; /var/lib/its/rm32_its/bin/bundle list` ti = 5 result = [] url_list.each { |url| rate_avg = 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 "T ¥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)“ }
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録｜Apache2.2, 2.4 148 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 通信圧縮
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録｜Passenger 149 Apache2 /etc/httpd/conf.d/passenger.conf # Rails environment settings # RailsEnv production # Multiple Redmine Envirnoment with Sub-URI RailsBaseURI /its RailsBaseURI /its_practice # 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
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録｜MySQL 5.6 150 ＜続き＞ 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
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録｜MySQL 5.6 for Bitnami 151 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 #================================================================
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録｜Subversion キャッシュ＆通信圧縮 152 Apache2.2, 2.4 /etc/httpd/conf.d/subversion.conf <IfModule dav_svn_module> SVNCompressionLevel 1 SVNInMemoryCacheSize 128000 SVNCacheFullTexts on SVNCacheTextDeltas on </IfModule>
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録｜ Redmine Subversion同期 153 Subversion Post-Commit-Hook - post-commit #!/bin/sh # Redmine のプロジェクト名とSubversionリポジトリ名が一致している条件下でのスクリプト # 名称不一致の場合、本スクリプト中に名称を指定すればよい。（数が多いと面倒なのでお勧めしません） 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
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録｜ Redmine OOBGC for Unicorn 154 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+
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録｜ Redmine OOBGC for Passenger 155 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'
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録｜ Redmine OOBGC for Passenger 156 ■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
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録｜ Redmine OOBGC for Passenger 157 Passengerへの gctools導入 ■ /etc/httpd/conf.d/passenger.conf にOOBGC用の設定値を指定 # For OOBGC < Experimental > PassengerSpawnMethod direct
Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録｜OS File System 158 ■/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 注意：ディスクにアクセスできなくなったり、システム・アプリケーションが正しく動作しなくなる危険性があります。 バックアップを確保したうえで、理解できる方だけ自己責任でチャレンジしてください。 危険性が高いわりに、性能向上は体感しにくいので、専門家以外には推奨しません。
終 Special Thanks to ブログ等で技術情報を公開して下さったみなさま 西川 撒さん My Family.

More Related Content

Redmineチューニングの実際と限界(旧資料) - Redmine performance tuning(old), See Below.

  • 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大阪 株式会社島津ビジネスシステムズ 基盤技術部 赤羽根 州晴 kakahane@sbs.shimadzu.co.jp
  • 3. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 話者紹介 赤羽根 州晴（@akahane92） 島津製作所 業務系システム子会社 ・ソフトウェア開発技術者 ↓障害対策専任 ↓内部統制 ・基盤技術標準化 (現在) 3 参加団体 ・Redmine大阪 ・AFFORDD 関西部会
  • 4. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved お話しすること 4 １）200万チケットでもサクサク動くRedmineの全レシピ* ２）Redmine2.6 を 3.4 へUpdateすると平均で○○％速くなる ３）Ruby2.0 を 2.4 へUpdateすると平均で○○％速くなる ４）HDDをSSDに変更すると平均で○○％速くなる ５）非索引型の全文検索は○○万チケットで性能限界に到達するが、 FTS-Pluginの導入によって○○倍速くなり、 200万チケットの環境で平均○○～○○秒で全文検索できる ６） Redmineチューニング事例 9種 *全レシピ： 設定値の一括ダウンロードはこちら (GitHub Gist) Download: Setting_paramaters_for_Redmine_Performance_Tuning.txt https://gist.github.com/akahane92/771f9a52d81af9864dd8
  • 5. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved お話ししないこと 5 １）大規模な並列トランザクション ２）DBMSチューニングの秘境探索
  • 6. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ご注意 6 本発表の内容には様々な設定が含まれていますが、 ご利用は自己責任でお願い致します。 参考になさった場合に生じたいかなる損害も補償できません。 あらかじめご了承下さい。
  • 7. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved Redmine使用状況 (アンケート結果） 7 使用しているRedmineは？ 有効回答数 69件、複数回答 （2017/8/26 Redmine大阪 #17） Redmine 3.0～3.3 65% Redmineを使用していない 17% Redmine 3.4.x 8% Redmine 2.x 10% Redmine 3.0～3.3 Redmineを使用していない Redmine 3.4.x Redmine 2.x Redmine 0.x Redmine 1.x trunk
  • 8. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved Redmine使用状況 (アンケート結果） 8 使用しているRedmineは？ 有効回答数 69件、複数回答 （2017/8/26 Redmine大阪 #17） Redmine 3.0～3.3 65% Redmineを使用していない 17% Redmine 3.4.x 8% Redmine 2.x 10% Redmine 3.0～3.3 Redmineを使用していない Redmine 3.4.x Redmine 2.x Redmine 0.x Redmine 1.x trunk Redmine3.x ：73％ Redmine2.x ：10％ 未使用 ：15％
  • 9. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved Redmine使用状況 (アンケート結果） 9 Redmineの環境と構築方法は？ ソース入手 （Linux), 21% 使用していない, 19% Bitnami(Window s), 15% Bitnami(Linux), 11% ソース入手 （Win), 11% 11% 6% 4% 0% ソース入手（Linux) 使用していない Bitnami(Windows) Bitnami(Linux) ソース入手（Win) その他 クラウドサービス VMイメージ RPM等パッケージ ソース入手（MacOS) ソース入手（JRuby) ALMinium 有効回答数 69件、複数回答 （2017/8/26 Redmine大阪 #17）
  • 10. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved Redmine使用状況 (アンケート結果） 10 Redmineの環境と構築方法は？ 有効回答数 62件、複数回答 （2017/8/26 Redmine大阪 #17） ソース入手 （Linux), 21% 使用していない, 19% Bitnami(Window s), 15% Bitnami(Linux), 11% ソース入手 （Win), 11% 11% 6% 4% 0% ソース入手（Linux) 使用していない Bitnami(Windows) Bitnami(Linux) ソース入手（Win) その他 クラウドサービス VMイメージ RPM等パッケージ ソース入手（MacOS) ソース入手（JRuby) ALMinium UNIX Like ：48％ Windows ：32％ その他 ：20％
  • 11. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved Redmine使用状況 (アンケート結果） 11 Redmineの使用年数は？ 有効回答数 69件、複数回答 （2017/8/26 Redmine大阪 #17） 3年以上 47% 使用していない 15% 使い始めたばかり 12% 1～3年ぐらい 15% 1年ぐらい 11% 3年以上 使用していない 使い始めたばかり 1～3年ぐらい 1年ぐらい
  • 12. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved Redmine使用状況 (アンケート結果） 12 Redmineの使用年数は？ 有効回答数 69件、複数回答 （2017/8/26 Redmine大阪 #17） 3年以上 47% 使用していない 15% 使い始めたばかり 12% 1～3年ぐらい 15% 1年ぐらい 11% 3年以上 使用していない 使い始めたばかり 1～3年ぐらい 1年ぐらい 使用者 85%
  • 13. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 教えて下さい 13 Redmine ・遅いと感じている方は？ ・性能チューニング経験は？ ・使用しているDBMSは？ （Postgresql、MySQL、SQLite、他） Eric Peacock https://www.flickr.com/photos/evilpeacock/6365513881/
  • 14. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次 14 第１部 背景と要求 第２部 チューニングの基本 第３部 ベンチマーク 第４部 性能改善事例集 第５部 まとめ 第６部 付録 14
  • 15. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次 15 第１部 背景と要求 第２部 チューニングの基本 第３部 ベンチマーク 第４部 性能改善事例集 第５部 まとめ 第６部 付録 15
  • 16. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 株式会社 島津製作所 2017年3月31日現在 創 業｜ 設 立｜ 資 本 金｜ 従 業 員 数 ｜ 3,422億円 (2017年3月期)グループ売上高｜ 社 是｜科学技術で社会に貢献する 経営理念｜｢人と地球の健康｣への願いを実現する 16 11,528名 (連結) 明治8（1875）年 大正6（1917）年 266億円
  • 17. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事業領域 産業機器 航空機器医用機器 分析・計測機器 17
  • 18. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要 18 島津製作所グループ 業務システム 情報系 子会社委託 IT全般統制 ISO 内部統制 省庁監査
  • 19. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要 19 島津製作所グループ 業務システム 情報系 子会社委託 IT全般統制 ISO 他 内部統制 省庁監査 複数の統制･認証に対応 大量の記録が必要
  • 20. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜背景モデル 20 要 件 結 果 業務用ITシステムの全般的な管理記録は 内部統制や各種認証（ISO,ISMS,省庁監査）の 要求に答えなければならない •記録と整合 •精査と承認 •追跡可能性 •目的合理性 •品質管理 •セキュリティー
  • 21. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜背景モデル 21 課題 3 課題・要望 問合せ受付 調査と確認 状況報告 方針決定 対処と確認 結果報告 時 間課題 2 変更 問合せ受付 調査と確認 状況報告 方針決定 対処と確認 結果報告 時 間課題 １ トラブル 問合せ受付 調査と確認 状況報告 方針決定 対処と確認 結果報告 時 間複数 ユーザー複数 ユーザー 複数 ユーザー 複数 ユーザー複数 ユーザー 複数 担当者 C事業部 B事業部 A事業部 X System Y System Z System 関係者増加 ／ 事案多様化／システム増加・分散 N ： N ： N
  • 22. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜業務システムの運営状況 22 業務システム １００種 利用者 7000人 事案 36000件 改版(コミット) 20000回 1700 KLOC 開発運用 ２００人 ／年 ／年 ／年 自動生成コード含む７～２0年超
  • 23. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜問題要約 23 1. 人の記憶が頼り「生き字引き」 2. システム毎の管理台帳で 情報お蔵入り 3. 経緯は 担当者のMail-Box に蓄積 4. システムと組織の壁が情報流通を阻害 5. パートナー契約、引継ぎ不足 6. 横断検索できない 7. ツールが現実を表現できない 8. 統制･監査･査察への対応負担増
  • 24. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜解決策 24 統合管理 全面導入 Issue Tracking System
  • 25. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜事案関係モデル 3.6万件／年 ２万コミット／年 ／年 関係性 25 記憶の消滅 × 二次元 Excel 表現できる…何か
  • 26. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜事案関係モデル 3.6万件／年 ２万コミット／年 ／年 関係性 26 記憶の消滅 × 二次元 Excel ITS OSS
  • 27. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜ITS導入の全体像 27 Project A 問合せ 要望･課題 障害･バグ タスク Project B 問合せ 要望･課題 障害･バグ タスク 課題管理システム (ITS) 版数管理ツール ■日常業務に浸透 •トータルで負担減少 •状態の掌握が容易 •コミュニケーション促進 ■トレーサビリティー 一意性 永続的な 連鎖性 履歴追跡性 ■変化への適応 状況変化を記録し追従 後々の参照が容易に SVN
  • 28. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜放置チケット対策の定着 28 週次ミーティングで、 積極的にチケット完了 ITSを使った会議
  • 29. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要 ・プロジェクト数、ユーザー数の経年変化 29 0 50 100 150 200 250 300 350 400 450 500 0 20 40 60 80 100 120 140 160 180 200 2010 2011 2012 2013 2014 2015 2016 2017 プロジェクト数 ITSユーザー数 ユ ー ザ ー 数 プ ロ ジ ェ ク ト 数 Project数182 User数 459 調査日 2017/7
  • 30. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜チケットの発行数と完了率 30 調査日 2017/7 0 10 20 30 40 50 60 70 80 90 100 0 5,000 10,000 15,000 20,000 25,000 30,000 35,000 40,000 45,000 50,000 2010 2011 2012 2013 2014 2015 2016 2017 完 了 率 チ ケ ッ ト 発 行 数 Ticket発行数 完了率 近似曲線（線形） 完了率 87% → 93% 累計 26万件 3,500/月 ％
  • 31. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 20 40 60 80 100 120 140 160 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 2010 2011 2012 2013 2014 2015 2016 2017 完 了 所 要 日 数 の 平 均 完 了 所 要 日 数 の 分 布 6ヶ月以上 6ヶ月 3ヶ月 1ヶ月 2週間 1週間 1日 平均完了日数 概要｜完了所要日数の分布と平均 調査日 2017/7 日 2011年 147日 2016年 41日
  • 32. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜チケット説明欄の文字数変化 32 0 100 200 300 400 500 600 700 800 900 1000 0 5,000 10,000 15,000 20,000 25,000 30,000 35,000 40,000 45,000 2009 2010 2011 2012 2013 2014 2015 2016 2017 チ ケ ッ ト 毎 の 記 録 文 字 数 チ ケ ッ ト 発 行 数 チケット発行数 説明欄文字数（平均） 近似曲線（線形） 2011年 529文字 2016年 738文字 調査日 2017/7 2016年 2億7千万文字 2017年 3億3千万文字 文字
  • 33. 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 2010 2011 2012 2013 2014 2015 2016 2017 チ ケ ッ ト 毎 の 添 付 フ ァ イ ル 数 チ ケ ッ ト 発 行 数 チケット発行数 添付ファイル数 1チケット毎の添付数 概要｜添付ファイル数の経年変化 33 ファイル 調査日 2017/7 2017年 26万3千 ファイル
  • 34. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜チケット関係性の経年変化 34 関係性カウント 線をカウントする 例）３カウント Ticket Ticket Ticket Ticket 関係記録数 2011年 11% 2015年 22% 調査日 2016/9 0% 5% 10% 15% 20% 25% 30% 0 5 10 15 20 25 2010 2011 2012 2013 2014 2015 2016 関 係 保 持 割 合 チ ケ ッ ト 発 行 数 の 累 計 万 チケット発行数累計 関係数累計 関係保持割合 線形 (関係保持割合)
  • 35. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 20 40 60 80 100 120 140 160 180 0 500 1,000 1,500 2,000 2,500 3,000 2010 2011 2012 2013 2014 2015 2016 2017 完 了 所 要 日 数 平 均 障 害 ・ バ グ チ ケ ッ ト 数 障害・バグチケット数 完了所要日数平均 概要｜障害･バグチケット数と完了所要日数の平均 35 調査日 2017/7 No Ticket, No Commit 開始 日 所要日数平均 157日 → 56日
  • 36. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜｢障害･バグ｣チケット密度 36 0 10 20 30 40 50 60 70 80 90 0 5,000 10,000 15,000 20,000 25,000 30,000 35,000 40,000 45,000 2011 2012 2013 2014 2015 2016 2017 障 害 ・ バ グ チ ケ ッ ト 密 度 チ ケ ッ ト 発 行 数 チケット発行数 障害･バグチケット発行数 障害･バグチケット密度 障害･バグチケット密度 (Spike除去) 2012年 59件/KT 2016年 52件/KT 調査日 2017/7 件／KT (Kilo Ticket)
  • 37. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜監査手続の定性評価 37 【例示】｢全てのIT統制対象システムにおいて、任意の 6ヶ月間に発生した全ての変更事案の中から、設計書と プログラムの両方、或いはいずれかを変更し、かつ、 データ強制変更を伴う事案の一覧を提出。ここから25 件をサンプリングし承認行為を示す証憑･証跡を提出｣ ３時間以内 複数人がかりで ２〜３日
  • 38. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜まとめ 38 統制実現 コスト低減 属人性軽減 品質, CS向上 業績貢献 【経営要求】 【現場要求】 現業務を表現可能 入力コストに見合う いつでもどこでも 素早く見つかる 休みやすい 【管理手法】 【統制要求】 IT全般統制 ISO 省庁監査 一意識別 ↓ 関連維持 ↓ 追跡可能 ↓ 信頼可能 現場の利益を動機とする 部分最適型の行動規範 が、結果として経営要求 を満たす統合情報基盤と して、全体最適型の均衡 を得た
  • 39. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 概要｜まとめ 39 １）100種の業務システムを200人が運用する現場 ２）IT統制に対応するため高水準の管理品質を維持 網羅性は必達（全員が全情報を入力し続ける） ３）文房具：常にサクサクの応答性能と盤石な安定性 ４）運営のための余力は皆無。省力化の徹底と、 安定性･信頼性の同時成立が不可欠（さもないと帰れない）
  • 40. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次 40 第１部 背景と要求 第２部 チューニングの基本 第３部 ベンチマーク 第４部 性能改善事例集 第５部 まとめ 第６部 付録 40
  • 41. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次 41 第１部 背景と要求 第２部 チューニングの基本 第３部 ベンチマーク 第４部 性能改善事例集 第５部 まとめ 第６部 付録 41
  • 42. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本 42図引用元： http://ja.wikipedia.org/wiki/ボトルネック概念図.png
  • 43. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本 43図引用元： http://ja.wikipedia.org/wiki/ボトルネック概念図.png 電子計算機 ネットワークシステム ボトルネックの 発見と解消
  • 44. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本  ボトルネックはどこか？ 44 ＃ 対 象 対 策 例 １ 通信 狭帯域を回避 Ethernet ２ 情報量 圧縮 HTML, Text ３ 電子計算 再処理を回避 多段キャッシュ ４ 永続化 高速装置へ置換 HDD ５ アルゴリズム 算法選択による 計算量削減 Sort, Index, GC
  • 45. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本  対策１ 狭帯域通信を避ける 45 Ethernet等の 低速通信 2M, 10M, 100Mbit / 秒 経路上の最も狭い帯域
  • 46. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved Local Loopback adapter 同一OS内のTCP/UDP/Socket通信 チューニングの基本  対策１ 狭帯域通信を避ける 46 狭帯域 ６→３
  • 47. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本  対策２ 情報量の圧縮 47 HTTP/1.1 Compression 情報量 1/4 ～ 1/10 最大10倍速
  • 48. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本  対策３ 再処理回避 48 Server Pass enge r RAID OS FS NW Ruby Rails Redmine DBMS HTTP Reverse Proxy Client Browser JavaScript / DOM OS FS NW
  • 49. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本  対策３ 再処理回避 49 Server Pass enge r RAID OS FS NW Ruby Rails Redmine DBMS HTTP Reverse Proxy Client Browser JavaScript / DOM OS FS NW ㋖㋖ ㋖㋖ ㋖ ㋖ ㋖ ㋖ ㋖ ㋖ ㋖ ㋖ ・潤沢なメモリ ・多段キャッシュ
  • 50. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本  対策４ 永続化 50* 情報の永続化 「電源をOFFにしてもデータが消えないようにすること」 Server Pass enge r RAID OS FS NW Ruby Rails Redmine DBMS HTTP Reverse Proxy 情報の永続化* SSDの登場 劇的な速度向上
  • 51. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本  対策５ 算法選択による計算量削減 51 算法の選択による 速度向上* Sort, GC, Index * 算法の変更によって計算処理量を減らし、より少ない時間で同一の処理を実施する Server Pass enge r RAID OS FS NW Ruby Rails Redmine DBMS HTTP Reverse Proxy
  • 52. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本  チューニング要点 52 Passenger5.1 OS CentOS7 （64bit） Ruby 2.4 Rails4.2 Redmine 3.4 DBMS MySQL 5.6 HTTP Apache 2.4 Memory 4〜16GBCPU 4〜6 Cores VMware （可用性、信頼性） VCS Subversion 1.8 HTTP Reverse Proxy --- ：8 Key Points Network
  • 53. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングの基本  チューニング要点 53 Passenger5.1 OS CentOS7 （64bit） Ruby 2.4 Rails4.2 Redmine 3.4 DBMS MySQL 5.6 HTTP Apache 2.4 Memory 4〜16GBCPU 4〜6 Cores VMware （可用性、信頼性） VCS Subversion 1.8 HTTP Reverse Proxy --- ：8 Key Points Network Redmine本体は変更しない 安定、安全、信頼
  • 54. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次 54 第１部 背景と要求 第２部 チューニングの基本 第３部 ベンチマーク 第４部 性能改善事例集 第５部 まとめ 第６部 付録 54
  • 55. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次 55 第１部 背景と要求 第２部 チューニングの基本 第３部 ベンチマーク 第４部 性能改善事例集 第５部 まとめ 第６部 付録 55
  • 56. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク 56 【背景】 ・年間36,000チケットを起票 ・業務の中心にITS（Redmine） ・処理遅延や障害停止の回避は必須 【2012年10月】 ・ITSの業務活用が急拡大（10万チケット越） ・200万チケットまでの動作を先行して確認 ・問題を洗い出して対策 【2015年5月、2016年3月、2017年7月】 ・2012年の予測値と、今までの実績値を比較 ・Redmine, Ruby, Rails, H/Wの変化 ・再度、性能ベンチマークを計測して最適解を選ぶ
  • 57. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク 57 “サクサク”の 基準
  • 58. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク 58 画面応答時間の基準*とは？ 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
  • 59. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク 59 画面応答時間の基準*とは？ 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は文房具
  • 60. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜実績値 60 Redmine月間アクセス数*の経年変化 * 8年分のApache アクセスログに記載されたURI - 2017年7月 0 500 1,000 1,500 2,000 2,500 0 5 10 15 20 25 30 35 40 2009 2010 2011 2012 2013 2014 2015 2016 2017 累 計 ア ク セ ス 数 万 月 間 ア ク セ ス 数 万 ITSアクセス数の経年変化 月平均 アクセス数累計 累計：2000万 月間：34万アクセス 調査日 2017/7
  • 61. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜実績値 8年間の運用結果*を集計 61 統計要約 最小値 : 1 第１四分位点 : 73 中央値 : 193 平均値 : 396 第３四分位点 : 317 最大値 :24708230 ・1443万回の処理 ・半分が200ms以下 ・95%が1秒以下 ・中央値193ms * 8年分のProduction.logに記載された処理応答時間 (Redmine～DB) - 2017年7月 調査日 2017/7 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超
  • 62. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜評価対象 8年間の運用結果*を集計し、主要画面を決定 62 ・2000万アクセス ・■チケット表示 ＋ ■チケット一覧で50% ・利用頻度、遅延 を体感しやすい画面 33% 17% 6% 5% 5% 4% 3% 3% 3% 2% 2% 2% 2% 1% 1% 11% 2000万アクセス ：ベンチマーク対象 チケット表示 チケット一覧 Wikiページ (Redmine_Draft) プロジェクトTop 検索（プロジェクト） 添付ダウンロード （Work_Time) ログイン画面 マイページ 添付画像サムネイル RedmineTop 時間入力 リポジトリ閲覧 チケット起票 その他 * 8年分のApache アクセスログに記載されたITSのURI - 2017年7月 調査日 2017/7
  • 63. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜評価対象 8年間の運用結果*を集計し、主要画面を決定 63 ・2000万アクセス ・■チケット表示 ＋ ■チケット一覧で50% ・利用頻度、遅延 を体感しやすい画面 ・ベンチマーク対象が 全体の59.4%を網羅 33% 17% 5% 3% 2% 2000万アクセス ：ベンチマーク対象 チケット表示 チケット一覧 Wikiページ (Redmine_Draft) プロジェクトTop 検索（プロジェクト） 添付ダウンロード （Work_Time) ログイン画面 マイページ 添付画像サムネイル RedmineTop 時間入力 リポジトリ閲覧 チケット起票 その他 * 8年分のApache アクセスログに記載されたITSのURI - 2017年7月 調査日 2017/7
  • 64. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜テストデータ* 64 規模 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万チケットを複写して製作 調査日 2017/7 200万チケットは ・3000万レコード ・14億9000万文字 カスタムフィールドは 77種に固定
  • 65. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜テストデータ* 65 200万チケットの内訳 種類 件数 チケット数 200万 カスタムField値 1,200万 添付ファイル 140万 時間記録 74万 注記欄 363万 ウォッチャー数 76万 Ticket間 参照数 27万 記録文字数 14億9,000万 プロジェクト数 113 ユーザー数 457 * 実データ10万チケットを複写して製作 調査日 2017/7
  • 66. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測方法 66 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 Ruby 2.3 Normal / OOBGC 3.3 / 3.4 Ruby 2.4 Normal 3.4 組合せ • OOBGC; Out Of Band Garbage Collection。Request処理中にRubyがGCを実行すると応答に遅延が生じる。 指定回数の処理毎に、間隙を縫ってGCを実行させることで応答の遅延を軽減する機能。 Passenger5.1 OS CentOS7 （64bit） Ruby 2.4 Rails4.2 Redmine 3.4 DBMS MySQL 5.6 （BP 8GB） HTTP Apache 2.4 Memory 16GBCPU 4cores VMware ESXi 6 【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
  • 67. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測方法 67 ① 主要画面8種に対して2並列でそれぞれ10回アクセスし、これを5回繰返して計測。 ② 上記①を、下記3種のDBキャッシュ状態を順次切り替えて計測。 DBキャッシュ無 → DBキャッシュ保存･復元 → Fullメモリキャッシュ ③ 上記②のFullメモリキャッシュの計測値を平均した値を採用。 ④ 上記①～③を、下記要素の全組み合わせ環境で繰り返す。 Redmineバージョン、 Rubyバージョン、OOGBC有無、 10万～200万チケット、SSD/HDD 10万 20万 30万 50万 70万 100万 150万 200万 所要時間合計（ミリ秒） 679.7 677.2 810.1 839.9 816.3 865.4 845.4 866.1 Redmine3.4 Ruby2.4.1 MySQL5.6 BufferPool 8G SSD 主要画面７種のURI /its34 14.2 14.3 14.8 13.1 13 12.9 13 12.9 /its34/projects 6.6 6.9 6.6 6.4 6.3 6.3 6.3 6.4 /its34/login 31 31.1 29.7 30.4 29.2 30 29.2 29 /its34/projects/sscope 89.1 87.6 86.4 87.5 84.4 86.2 84.1 84.3 /its34/issues?per_page=200 224.5 217.5 227.2 231.1 215.6 230 216.2 215 /its34/issues/1 86.9 69.1 186.5 194.3 184.8 191.6 182 184.5 /its34/issues/47548 149.4 161.3 168.6 184.1 192.8 215.3 225.5 244 /its34/issues/51782 78 89.4 90.3 93 90.2 93.1 89.1 90 調査日 2017/7
  • 68. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 2000 4000 6000 8000 10000 12000 Ruby2.0 nml Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.2 oobgc Ruby2.3 oobgc 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果１ 68 Redmine3.3の最速ベンチ ms 調査日 2017/7
  • 69. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 2000 4000 6000 8000 10000 12000 Ruby2.0 nml Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.2 oobgc Ruby2.3 oobgc 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果１ 69 Redmine3.3の最速ベンチ ms 最も遅い Ruby2.0 に比して、 最も速い Ruby2.3+OOBGC は 32.1% 速い 調査日 2017/7
  • 70. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果１ 70 Redmine3.4の最速ベンチ 0 2000 4000 6000 8000 10000 12000 Ruby2.0 nml Ruby2.3 oobgc Ruby2.2 oobgc Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.4 nml 10万 20万 30万 50万 70万 100万 150万 200万 ms 調査日 2017/7
  • 71. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果１ 71 Redmine3.4の最速ベンチ 0 2000 4000 6000 8000 10000 12000 Ruby2.0_nml Ruby2.3_oobgc Ruby2.2_oobgc Ruby2.1_oobgc Ruby2.1_nml Ruby2.2_nml Ruby2.3_nml Ruby2.4_nml 10万 20万 30万 50万 70万 100万 150万 200万 ms 最も遅い Ruby2.0 に比して、 最も速い Ruby2.4 は 26.9% 速い 調査日 2017/7
  • 72. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 Redmine 2.6 Redmine 3.0 Redmine 3.1 Redmine 3.2 Redmine 3.3 Redmine 3.4 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果２ 72 Redmine3.4は速いのか ms 調査日 2017/7
  • 73. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 Redmine 2.6 Redmine 3.0 Redmine 3.1 Redmine 3.2 Redmine 3.3 Redmine 3.4 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果２ 73 Redmine3.4は速いのか ms ・性能向上（平均） 2.6 → 3.0 8.8% 2.6 → 3.1 5.6% 2.6 → 3.2 4.2% 2.6 → 3.3 3.5% 2.6 → 3.4 24.9% ・原因推測 ＋ Redmine3.4 ＋ Ruby2.4 － 機能増加 調査日 2017/7
  • 74. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 Redmine 2.6 Redmine 3.0 Redmine 3.1 Redmine 3.2 Redmine 3.3 Redmine 3.4 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果２ 74 Redmine3.4は速いのか ms ・性能向上（平均） 2.6 → 3.0 8.8% 2.6 → 3.1 5.6% 2.6 → 3.2 4.2% 2.6 → 3.3 3.5% 2.6 → 3.4 24.9% ・原因推測 ＋ Redmine3.4 ＋ Ruby2.4 － 機能増加Redmine2.6から3.4へアップデートすると、 平均で24.9％の性能向上が得られる 調査日 2017/7
  • 75. 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.3 oobgc Ruby2.2 oobgc Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.4 nml Redmine 3.4 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果３ 75 Rubyバージョン変更の効果 Ruby2.0 nml Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.2 oobgc Ruby2.3 oobgc Redmine3.3 10万 20万 30万 50万 70万 100万 150万 200万 ms 調査日 2017/7
  • 76. 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.3 oobgc Ruby2.2 oobgc Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.4 nml Redmine 3.4 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果３ 76 Rubyバージョン変更の効果 Ruby2.0 nml Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.2 oobgc Ruby2.3 oobgc Redmine3.3 10万 20万 30万 50万 70万 100万 150万 200万 Redmine3.4 性能向上(平均) Ruby2.0→2.4 26.9% Ruby2.0→2.3OOBGC 24.5% Redmine3.3 性能向上(平均) Ruby2.0→2.3 31.2% Ruby2.0→2.3OOBGC 32.1% ms 調査日 2017/7
  • 77. 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.3 oobgc Ruby2.2 oobgc Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.4 nml Redmine 3.4 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果３ 77 Rubyバージョン変更の効果 Ruby2.0 nml Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.2 oobgc Ruby2.3 oobgc Redmine3.3 10万 20万 30万 50万 70万 100万 150万 200万 Redmine3.4 性能向上(平均) Ruby2.0→2.4 26.9% Ruby2.0→2.3OOBGC 24.5% Redmine3.3 性能向上(平均) Ruby2.0→2.3 31.2% Ruby2.0→2.3OOBGC 32.1% Redmine3.4において、Ruby2.0から2.4へ Updateすると平均26.9％の性能向上が得られる 調査日 2017/7 ms
  • 78. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果３ 78 OOBGCの効果 78 Ruby2.0 nml Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.2 oobgc Ruby2.3 oobgc Redmine3.3 10万 20万 30万 50万 70万 100万 150万 200万 調査日 2017/7 0 2,000 4,000 6,000 8,000 10,000 12,000 Ruby2.0 nml Ruby2.3 oobgc Ruby2.2 oobgc Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.4 nml Redmine 3.4 10万 20万 30万 50万 70万 100万 150万 200万 ms
  • 79. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果３ 79 OOBGCの効果 0 2,000 4,000 6,000 8,000 10,000 12,000 Ruby2.0 nml Ruby2.3 oobgc Ruby2.2 oobgc Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.4 nml Redmine 3.4 10万 20万 30万 50万 70万 100万 150万 200万 79 Ruby2.0 nml Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.2 oobgc Ruby2.3 oobgc Redmine3.3 10万 20万 30万 50万 70万 100万 150万 200万 Redmine3.3 性能向上(平均) OOBGC効果 Ruby2.2→2.2OOBGC 3.6% Redmine3.4 性能向上(平均) OOBGC効果 Ruby2.3→2.3OOBGC -7.1% 調査日 2017/7 ms
  • 80. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ms ベンチマーク｜計測結果３ 80 OOBGCの効果 0 2,000 4,000 6,000 8,000 10,000 12,000 Ruby2.0 nml Ruby2.3 oobgc Ruby2.2 oobgc Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.4 nml Redmine 3.4 10万 20万 30万 50万 70万 100万 150万 200万 80 Ruby2.0 nml Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.2 oobgc Ruby2.3 oobgc Redmine3.3 10万 20万 30万 50万 70万 100万 150万 200万 Redmine3.3 性能向上(平均) OOBGC効果 Ruby2.2→2.2OOBGC 3.6% Redmine3.4 性能向上(平均) OOBGC効果 Ruby2.3→2.3OOBGC -7.1% Redmine3.3において、Ruby2.3にOOBGCを適用すると 平均 3.1％の性能向上が得られる Redmine3.4において、Ruby2.3にOOBGCを適用すると 平均 -7.1％の性能低下が生じる 調査日 2017/7
  • 81. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ms ベンチマーク｜計測結果３ 81 OOBGCの効果 0 2,000 4,000 6,000 8,000 10,000 12,000 Ruby2.0 nml Ruby2.3 oobgc Ruby2.2 oobgc Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.4 nml Redmine 3.4 10万 20万 30万 50万 70万 100万 150万 200万 81 Ruby2.0 nml Ruby2.1 oobgc Ruby2.1 nml Ruby2.2 nml Ruby2.3 nml Ruby2.2 oobgc Ruby2.3 oobgc Redmine3.3 10万 20万 30万 50万 70万 100万 150万 200万 Redmine3.3 性能向上(平均) OOBGC効果 Ruby2.2→2.2OOBGC 3.6% Redmine3.4 性能向上(平均) OOBGC効果 Ruby2.3→2.3OOBGC -7.1% Redmine3.3において、Ruby2.3にOOBGCを適用すると 平均 3.1％の性能向上が得られる Redmine3.4において、Ruby2.3にOOBGCを適用すると 平均 -7.1％の性能低下が生じる 調査日 2017/7 【事実】 今回の計測では、Redmine3.4ではOOBGCの効果が 出なくなった。 【推測】 本ベンチマークの処理条件においては、Redmine3.4 の内部処理変更によってオブジェクト生成と破棄が少 なくなり、5回に1度の高頻度なOOBGCは不要（処理 コスト＞メリット）になったのではないかと推測。 【知見】 Ruby2.3でRedmine3.4を動作させる場合は、利用条 件によってOOBGCが有効でない場合があるとわかっ た。 Redmine3.4は、Ruby2.4で動作させるのが最速。
  • 82. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果４ 82 過去のRedmineと比較 Redmine自体は速くなった？遅くなった？ 調査日 2017/7
  • 83. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 1,000 2,000 3,000 4,000 5,000 6,000 7,000 8,000 9,000 Redmine1.4 最 速 Redmine2.0 最 速 Redmine2.1 最 速 Redmine2.3 最 速 Redmine2.6 最 速 Redmine3.0 最 速 Redmine3.1 最 速 Redmine3.2 最 速 Redmine3.3 最 速 Redmine3.4 最 速 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果４ 83 過去のRedmineと比較 ms 調査日 2017/7
  • 84. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 1,000 2,000 3,000 4,000 5,000 6,000 7,000 8,000 9,000 Redmine1.4 最 速 Redmine2.0 最 速 Redmine2.1 最 速 Redmine2.3 最 速 Redmine2.6 最 速 Redmine3.0 最 速 Redmine3.1 最 速 Redmine3.2 最 速 Redmine3.3 最 速 Redmine3.4 最 速 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果４ 84 過去のRedmineと比較 最速ベンチマークを 比較すると、 2.3 → 2.6 - 30% 2.3 → 3.4 - 5.9% 性能が低下してい る。 ms 調査日 2017/7
  • 85. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 1,000 2,000 3,000 4,000 5,000 6,000 7,000 8,000 9,000 Redmine1.4 最 速 Redmine2.0 最 速 Redmine2.1 最 速 Redmine2.3 最 速 Redmine2.6 最 速 Redmine3.0 最 速 Redmine3.1 最 速 Redmine3.2 最 速 Redmine3.3 最 速 Redmine3.4 最 速 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果４ 85 過去のRedmineと比較 ms 性能変化の原因推測 ＋ Redmine内部改善 ＋ Ruby高速化 ＋ Multi Thread対応 ＋ Rails4.2の内部改善 － 機能増加 ※ Redmine2.3以前の計測は当時の 計算機とRuby1.8, 1.9, 2.0による もの。現在は電算機の能力が向上し ており比較精度は完全でない。よっ て参考値とする。 調査日 2017/7
  • 86. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 1,000 2,000 3,000 4,000 5,000 6,000 7,000 8,000 9,000 Redmine1.4 最 速 Redmine2.0 最 速 Redmine2.1 最 速 Redmine2.3 最 速 Redmine2.6 最 速 Redmine3.0 最 速 Redmine3.1 最 速 Redmine3.2 最 速 Redmine3.3 最 速 Redmine3.4 最 速 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果４ 86 過去のRedmineと比較 ms 機能増加 Redmine 2.3, 2.4, 2.5, 2.6, 3.0, 3.1, 3.2, 3.3, 3,4 Spent time 2013-03 ～ 2017-07 Includes 306 Features implemented 495 Patches applied 561 Defects fixed Still very fast and reliable! 調査日 2017/7
  • 87. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 1,000 2,000 3,000 4,000 5,000 6,000 7,000 8,000 9,000 Redmine1.4 最 速 Redmine2.0 最 速 Redmine2.1 最 速 Redmine2.3 最 速 Redmine2.6 最 速 Redmine3.0 最 速 Redmine3.1 最 速 Redmine3.2 最 速 Redmine3.3 最 速 Redmine3.4 最 速 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果４ 87 過去のRedmineと比較 ms 機能増加 Redmine 2.3, 2.4, 2.5, 2.6, 3.0, 3.1, 3.2, 3.3, 3,4 Spent time 2013-03 ～ 2017-07 Includes 192 Features 294 Patches 406 Defects repaired Still so fast and reliable! ・Redmine2.3を3.4へUpdateすると5.9%性能が 低下する ・多くの有益な機能が追加されている。 コア開発チームの努力と技術の進歩により、 応答性能の低下は最小限にとどまった。 調査日 2017/7
  • 88. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜小まとめ 88 Redmine3.4の性能が大幅に改善した主な理由 理由1：Ruby2.3, 2.4の処理性能向上 Ex. Towards Faster Ruby Hash Tables Vladimir Makarov 理由2：Redmine core パフォーマンス改善11種 Issue# Subject 25022 Add an index on attachments.disk_filename 24865 Load associations of query results more efficiently 24839 Minor performance improvement - Replace count by exists? 24787 Don't preload all filter values when displaying issues/time entries 24587 Improve custom fields list performance 24433 The changeset display is slow when changeset_issues has very many records 23987 Add an index on issues.parent_id 23743 Add index to workflows.tracker_id 23519 Don't preload projects and roles on Principal#memberships association 22850 Speedup remove_inherited_roles 21608 Project#allowed_to_condition performance
  • 89. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果5 89 今回のベンチマークはSSD主体で行った。 HDDとSSDの性能差はどの程度か？
  • 90. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 2000 4000 6000 8000 10000 12000 Redmine2.3 HDD Redmine2.6 HDD Redmine3.4 HDD Redmine3.4 SSD 10万 20万 30万 50万 70万 100万 150万 200万 ms ベンチマーク｜計測結果５ 90 HDDをSSDに置換する効果 調査日 2017/7
  • 91. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 2000 4000 6000 8000 10000 12000 Redmine2.3 HDD Redmine2.6 HDD Redmine3.4 HDD Redmine3.4 SSD 10万 20万 30万 50万 70万 100万 150万 200万 ms ベンチマーク｜計測結果５ 91 HDDをSSDに置換する効果 Redmine3.4 HDD → SSD 平均18.6%の性能向上 【参考】2015年5月の調査 平均25.7%の性能向上 （今回の調査でSSDの性能を生 かし切れていない可能性） 調査日 2017/7
  • 92. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 2000 4000 6000 8000 10000 12000 Redmine2.3 HDD Redmine2.6 HDD Redmine3.4 HDD Redmine3.4 SSD 10万 20万 30万 50万 70万 100万 150万 200万 ms ベンチマーク｜計測結果５ 92 HDDをSSDに置換する効果 【参考】2015年5月の調査 平均25.7%の性能向上 （今回の調査でSSDの性能を生 かし切れていない可能性） HDDをSSDに交換すると、環境によって 平均18.6％～25.7％の性能向上が得られる Redmine3.4 HDD → SSD 平均18.6%の性能向上 調査日 2017/7
  • 93. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果６ 93 複数プラグイン導入の性能への影響 Redmineの性能に、プラグインがどの程度 の影響を与えるのか？
  • 94. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果６ 94 複数プラグイン導入の性能への影響 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
  • 95. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果６ 95 複数プラグイン導入の性能への影響 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
  • 96. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果７ 96 FTS* 応答性能の計測 * FTS; Full Text Search 全文検索（索引型／非索引型） Redmineの全文検索性能は改善されたのか？ FullTextSearchプラグインの導入によって、 どの程度の高速化されるのか？
  • 97. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 2,000 4,000 6,000 8,000 10,000 12,000 14,000 No Cash BP Save & Load Full Cash No Cash BP Save & Load Full Cash No Cash BP Save & Load Full Cash Redmine3.0 非索引型 Redmine3.3 非索引型 Redmine3.3 索引型 全 文 検 索 所 用 時 間 積 算 （ 秒 ） 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果７ 97 FTS* 応答性能の計測 秒 調査日 2017/7 * FTS; Full Text Search 全文検索（索引型／非索引型） * BP; データベースのBuffer Pool メモリ。一度読込んだらメモリ上に貯蔵してDisk I/Oを削減 非索引型 索引型 Redmineの全文検索処理 ・非索引型 ・索引型（プラグイン導入） Redmine Full Text Search V0.4.0
  • 98. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 2,000 4,000 6,000 8,000 10,000 12,000 14,000 No Cash BP Save & Load Full Cash No Cash BP Save & Load Full Cash No Cash BP Save & Load Full Cash Redmine3.0 非索引型 Redmine3.3 非索引型 Redmine3.3 索引型 全 文 検 索 所 用 時 間 積 算 （ 秒 ） 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果７ 98 FTS* 応答性能の計測 秒 調査日 2017/7 * FTS; Full Text Search 全文検索（索引型／非索引型） * BP; データベースのBuffer Pool メモリ。一度読込んだらメモリ上に貯蔵してDisk I/Oを削減 非索引型 索引型 Redmineの全文検索処理 ・非索引型 ・索引型（プラグイン導入） Redmine Full Text Search V0.4.0 計測時のDBキャッシュ状態３種 ・No Cash ・BP* Save & Load（実用検索） ・Full Cashed 計測対象 1) /its33/search?q=ATO 2) /its33/search?q=WIP 3) /its33/search?q=sSCOPE ※ 実行条件、回数等は共通
  • 99. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved * FTS; Full Text Search 全文検索（索引型／非索引型） * BP; データベースのBuffer Pool メモリ。一度読込んだらメモリ上に貯蔵してDisk I/Oを削減 0 2,000 4,000 6,000 8,000 10,000 12,000 14,000 No Cash BP Save & Load Full Cash No Cash BP Save & Load Full Cash No Cash BP Save & Load Full Cash Redmine3.0 非索引型 Redmine3.3 非索引型 Redmine3.3 索引型 全 文 検 索 所 用 時 間 積 算 （ 秒 ） 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果７ 99 FTS* 応答性能の計測 秒 調査日 2017/7 Redmine3.0の全文検索処理 【非索引型】 ・No Cash： 12,193秒 10万チケット 24秒 100万チケット 207秒 200万チケット 6204秒 ・BP Save & Load： 9,415秒 10万チケット 17秒 100万チケット 162秒 200万チケット 3601秒 ・Full Cashed： 13秒 10万チケット 0.3秒 100万チケット 2.2秒 200万チケット 2.7秒 非索引型 索引型
  • 100. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved * FTS; Full Text Search 全文検索（索引型／非索引型） * BP; データベースのBuffer Pool メモリ。一度読込んだらメモリ上に貯蔵してDisk I/Oを削減 0 2,000 4,000 6,000 8,000 10,000 12,000 14,000 No Cash BP Save & Load Full Cash No Cash BP Save & Load Full Cash No Cash BP Save & Load Full Cash Redmine3.0 非索引型 Redmine3.3 非索引型 Redmine3.3 索引型 全 文 検 索 所 用 時 間 積 算 （ 秒 ） 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果７ 100 FTS* 応答性能の計測 調査日 2017/7 秒 非索引型 索引型 Redmine3.3の全文検索処理 【非索引型】 ・No Cash： 555秒 10万チケット 2秒 100万チケット 12秒 200万チケット 295秒 ・BP* Save & Load： 421秒 10万チケット 1秒 100万チケット 12秒 200万チケット 222秒 ・Full Cashed： 26秒 10万チケット 0.5秒 100万チケット 5秒 200万チケット 8秒
  • 101. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果７ 101 FTS 応答性能の計測 調査日 2017/7 Redmine3.3の全文検索処理 【非索引型】 ・No Cash： 555秒 10万チケット 2秒 100万チケット 12秒 200万チケット 295秒 ・BP Save & Load： 421秒 10万チケット 1秒 100万チケット 12秒 200万チケット 222秒 ・Full Cashed： 26秒 10万チケット 0.5秒 100万チケット 5秒 200万チケット 8秒 0 100 200 300 400 500 600 No Cash BP Save & Load Full Cash No Cash BP Save & Load Full Cash Redmine3.3 非索引型 Redmine3.3 索引型 検 索 所 用 時 間 積 算 （ 秒 ） 10万 20万 30万 50万 70万 100万 150万 200万 秒 非索引型 索引型
  • 102. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 0 100 200 300 400 500 600 No Cash BP Save & Load Full Cash No Cash BP Save & Load Full Cash Redmine3.3 非索引型 Redmine3.3 索引型 検 索 所 用 時 間 積 算 （ 秒 ） 10万 20万 30万 50万 70万 100万 150万 200万 ベンチマーク｜計測結果７ 102 FTS 応答性能の計測 調査日 2017/7 非索引型 索引型 Redmine3.3の全文検索処理 【索引型】 ・No Cash： 25秒 10万チケット 0.5秒 100万チケット 4秒 200万チケット 8秒 ・BP Save & Load： 19秒 10万チケット 0.4秒 100万チケット 3秒 200万チケット 6秒 （実用検索） ・Full Cashed： 16秒 10万チケット 0.4秒 100万チケット 2秒 200万チケット 5秒 秒
  • 103. 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 23.5 39.6 61.4 100.4 143.2 206.9 5,415.2 6,203.4 1,524 BP Save & Load 17.1 32.5 52.7 80.6 112.6 162.6 5,355.9 3,601.6 1,177 Full Cash 0.4 0.6 0.8 1.2 1.6 2.3 2.7 3.3 2 Redmine 3.3 非索引型 No Index No Cash 1.6 3.0 4.6 7.5 8.1 11.9 224.0 295.7 70 BP Save & Load 1.1 1.9 2.9 4.7 8.0 11.8 169.4 222.0 53 Full Cash 0.5 0.9 1.2 2.1 2.9 4.5 6.1 8.3 3 Redmine 3.3 索引型 FTS Indices No Cash 0.5 0.9 1.2 2.0 2.7 3.8 6.0 8.0 3 BP Save & Load 0.4 0.7 0.9 1.5 2.1 2.9 4.5 6.0 2 Full Cash 0.4 0.6 0.8 1.2 1.7 2.4 3.8 4.9 2 ベンチマーク｜計測結果７ 103 FTS 応答性能の計測 調査日 2017/7 全文検索 所用時間（秒 sec）
  • 104. 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 23.5 39.6 61.4 100.4 143.2 206.9 5,415.2 6,203.4 1,524 BP Save & Load 17.1 32.5 52.7 80.6 112.6 162.6 5,355.9 3,601.6 1,177 Full Cash 0.4 0.6 0.8 1.2 1.6 2.3 2.7 3.3 2 Redmine 3.3 非索引型 No Index No Cash 1.6 3.0 4.6 7.5 8.1 11.9 224.0 295.7 70 BP Save & Load 1.1 1.9 2.9 4.7 8.0 11.8 169.4 222.0 53 Full Cash 0.5 0.9 1.2 2.1 2.9 4.5 6.1 8.3 3 Redmine 3.3 索引型 FTS Indices No Cash 0.5 0.9 1.2 2.0 2.7 3.8 6.0 8.0 3 BP Save & Load 0.4 0.7 0.9 1.5 2.1 2.9 4.5 6.0 2 Full Cash 0.4 0.6 0.8 1.2 1.7 2.4 3.8 4.9 2 ベンチマーク｜計測結果７ 104 FTS 応答性能の計測 調査日 2017/7 全文検索 所用時間（秒 sec） 非索引型の全文検索は10～20万チケットで性能限界に到達する。
  • 105. 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 23.5 39.6 61.4 100.4 143.2 206.9 5,415.2 6,203.4 1,524 BP Save & Load 17.1 32.5 52.7 80.6 112.6 162.6 5,355.9 3,601.6 1,177 Full Cash 0.4 0.6 0.8 1.2 1.6 2.3 2.7 3.3 2 Redmine 3.3 非索引型 No Index No Cash 1.6 3.0 4.6 7.5 8.1 11.9 224.0 295.7 70 BP Save & Load 1.1 1.9 2.9 4.7 8.0 11.8 169.4 222.0 53 Full Cash 0.5 0.9 1.2 2.1 2.9 4.5 6.1 8.3 3 Redmine 3.3 索引型 FTS Indices No Cash 0.5 0.9 1.2 2.0 2.7 3.8 6.0 8.0 3 BP Save & Load 0.4 0.7 0.9 1.5 2.1 2.9 4.5 6.0 2 Full Cash 0.4 0.6 0.8 1.2 1.7 2.4 3.8 4.9 2 ベンチマーク｜計測結果７ 105 FTS 応答性能の計測 調査日 2017/7 全文検索 所用時間（秒 sec） 非索引型の全文検索は10～20万チケットで性能限界に到達する。 Redmine3.3に索引型の全文検索Pluginを導入すると、実用的な検索 速度は3.0に比べて平均で約490倍速くなり、
  • 106. 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 23.5 39.6 61.4 100.4 143.2 206.9 5,415.2 6,203.4 1,524 BP Save & Load 17.1 32.5 52.7 80.6 112.6 162.6 5,355.9 3,601.6 1,177 Full Cash 0.4 0.6 0.8 1.2 1.6 2.3 2.7 3.3 2 Redmine 3.3 非索引型 No Index No Cash 1.6 3.0 4.6 7.5 8.1 11.9 224.0 295.7 70 BP Save & Load 1.1 1.9 2.9 4.7 8.0 11.8 169.4 222.0 53 Full Cash 0.5 0.9 1.2 2.1 2.9 4.5 6.1 8.3 3 Redmine 3.3 索引型 FTS Indices No Cash 0.5 0.9 1.2 2.0 2.7 3.8 6.0 8.0 3 BP Save & Load 0.4 0.7 0.9 1.5 2.1 2.9 4.5 6.0 2 Full Cash 0.4 0.6 0.8 1.2 1.7 2.4 3.8 4.9 2 ベンチマーク｜計測結果７ 106 FTS 応答性能の計測 調査日 2017/7 全文検索 所用時間（秒 sec） 非索引型の全文検索は10～20万チケットで性能限界に到達する。 Redmine3.3に索引型の全文検索Pluginを導入すると、実用的な検索 速度は3.0に比べて平均で約490倍速くなり、10万チケットを平均0.4 秒、200万チケット（≒15億文字）を平均6秒で検索可能になる。 2 million tickets include approximately 1.5 billion multibyte characters. Indexed FTS takes 6 sec.
  • 107. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果８ 107 Redmine3.4は200万チケットでも “サクサク”なのか？ 0 100 200 300 400 500 600 700 800 900 1000 10万 20万 30万 50万 70万 100万 150万 200万 チケット表示（小） チケット表示（大） チケット表示（中） チケット一覧 プロジェクトTop プロジェクト一覧 ログイン画面 Redmine Top ms 調査日 2017/7
  • 108. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果８ 108 Redmine3.4は200万チケットでも “サクサク”なのか？ 0 100 200 300 400 500 600 700 800 900 1000 10万 20万 30万 50万 70万 100万 150万 200万 チケット表示（小） チケット表示（大） チケット表示（中） チケット一覧 プロジェクトTop プロジェクト一覧 ログイン画面 Redmine Top ms チューニングの結果、Redmine3.4の 主要画面8種の平均応答時間は100ms 調査日 2017/7
  • 109. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果８ 109 Redmine3.4は200万チケットでも “サクサク”なのか？ 0 100 200 300 400 500 600 700 800 900 1000 10万 20万 30万 50万 70万 100万 150万 200万 チケット表示（小） チケット表示（大） チケット表示（中） チケット一覧 プロジェクトTop プロジェクト一覧 ログイン画面 Redmine Top ms ①全文検索 20秒 Full_Text_Search Plugin ②DB始動時の暖機運転5分 MySQL5.6, Postgres9.4に対策有り (BufferPool dump/Restore) 調査日 2017/7 ③BufferPool 8GB以上必須
  • 110. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved ベンチマーク｜計測結果８ 110 Redmine3.4は200万チケットでも “サクサク”なのか？ 0 100 200 300 400 500 600 700 800 900 1000 10万 20万 30万 50万 70万 100万 150万 200万 チケット表示（小） チケット表示（大） チケット表示（中） チケット一覧 プロジェクトTop プロジェクト一覧 ログイン画面 Redmine Top ms 調査日 2017/7 ③BufferPool 8GB以上必須 ①全文検索 20秒 Full_Text_Search Plugin ②DB始動時の暖機運転5分 MySQL5.6, Postgres9.4に対策有り (BufferPool dump/Restore) 3点対策して環境を整備すれば 200万チケットまで大丈夫
  • 111. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次 111 第１部 背景と要求 第２部 チューニングの基本 第３部 ベンチマーク 第４部 性能改善事例集 第５部 まとめ 第６部 付録 111
  • 112. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次 112 第１部 背景と要求 第２部 チューニングの基本 第３部 ベンチマーク 第４部 性能改善事例集 第５部 まとめ 第６部 付録 112
  • 113. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 性能改善事例集 113 1. 8年間に渡るRedmineの運用におい て、どのような問題が発生し、どう やって解消したのか 2. 信頼性と安定性を維持する取組みの 「実際と限界」に焦点 3. 各種設定、チューニング方法、性能計 測方法を全て紹介する
  • 114. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 計測 - 定量化手法 ｢測定できないものは制御できない｣* １．テスト実行時間 （Redmine Built-in Test Code） ２．負荷ベンチマーク ・httpref http://www.hpl.hp.com/research/linux/httperf/ ・wrk https://github.com/wg/wrk ・apache bench http://httpd.apache.org/docs/2.2/programs/ab.html ３．時間計測 ・MySQL Slow-query ログ ・Redmineログ （Production.log, Development.log） ４．分析 ・SQL実行計画（MySQL Workbench） https://www-jp.mysql.com/products/workbench/ ・Chrome開発者ツール https://developer.chrome.com/devtools ・ネットワークスループット調査 iperf https://iperf.fr/ (Win版は× : ブルースクリーン死亡） 114* DeMarco, Tom., 1982, “You can’t control what you can't measure.”
  • 115. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved チューニングチェックリスト20 １／２ 115 １）Memory搭載・設定 DBMSに十分なキャッシュメモリを付与 ２）Disk I/O HDD→ SSD ３）CPUコア数と同時並行処理数 ４）OS選択 Linux ／ 起動プロセスとパッケージは必要最低限に削ぎ落とす。 ５）DBMS選択 MySQL, Postgresql を使用して、必ず設定値を変更。 ６）通信データ圧縮 Apache等 HTTP/1.1 Compression ７）Rubyバージョン利用可能な最新版を使用 1.9 < 2.0 < < < 2.1 < 2.2 < 2.3 << 2.4 ８）Webアプリケーションサーバー選択 WEBrick < < < Thin < < Passenger4 ≒ Passenger5 ９）通信経路の狭帯域対策 10M/bps → 1G/bps (ケーブル交換、装置交換) 同一サーバーに置くことで通信帯域を広くする。Local Loopback は最速のNIC １０）通信装置の性能向上 Normal-HubをSwitching-Hubへ交換しコリジョンによる通信効率低下を回避 １１）Subversionリポジトリの同期トリガを変更
  • 116. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 116 １２）Subversionリポジトリの同期対象を指定する １３）Subversionセッションキャッシュを付与する １４）Subversion通信圧縮機能を利用する １５）MySQLメモリチューニング メモリを十分に付与し、全インデックスや全データをできるだけオンメモリ化 １６）カスタムフィールドの設定 「検索対象」の数が多いと極端に性能が落ちる １７）DBMSサーバーの「暖機運転」 MySQL 5.6： Buffer-Pool Save & Load PostgreSQL 9.4： pg_prewarm １８）メール非同期送信（Async） １９）Plugin導入数 ２0）RubyとGC ・内部処理の大幅改善によりRuby2.4が最速のバージョン ・2位は Ruby2.3＋OOBGC（調査時点 2017/07 ） チューニングチェックリスト20 １／２
  • 117. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例１）【性能】全体がひどく遅い 117 【チューニング要素】 ・H/W: HDD, Memory, CPU ・S/W: OS, DBMS, Http Server, Ruby, WebAppServer ・N/W: 通信帯域, Switching-Hub １）Memory搭載・設定 DBMSに十分なキャッシュメモリを付与 ２）Disk I/O HDD→ SSD OS, DBMS, APL（Redmine他）はSSDに格納し、他のデータはHDDへ ３）CPUコア数と同時並行処理数 処理要求が集中した時の待ち行列 CPUコアやHTスレッド数に合わせて並行度を上げ、最大待ち時間を低く抑える。 - Passenger：自動調整 （指定可能） - Unicorn , Thin：起動サーバー数を増減
  • 118. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例１）【性能】全体がひどく遅い 118 【チューニング要素】 ・H/W: HDD, Memory, CPU ・S/W: OS, DBMS, Http Server, Ruby, WebAppServer ・N/W: 通信帯域, Switching-Hub ４）OS選択 Windows Bitnamiは５万件まで（制約：Ruby2.0系, DBMS 32bit） 最新のBitnami 3.3、3.4系はRuby2.3に。未調査だが期待。（制約：DBMS 32bit） 10万件扱うなら、Windows スクラッチ構築 15万件以上扱うなら200万件まで確認したLinux 64bitを推奨 ５）DBMS選択 MySQL, Postgresql を使用して、必ず設定値を変更。Sqliteは１万チケットまで ６）通信データ圧縮 Apache等 HTTP/1.1 Compression ネットワーク帯域が狭い時、通信輻輳時に高い効果
  • 119. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例１）【性能】全体がひどく遅い 119 【チューニング要素】 ・H/W: HDD, Memory, CPU ・S/W: OS, DBMS, Http Server, Ruby, WebAppServer ・N/W: 通信帯域, Switching-Hub ７）Rubyバージョン 利用可能な最新版を使用 1.9 < 2.0 < < < 2.1 < 2.2 < 2.3 << 2.4 ８）Webアプリケーションサーバー選択 WEBrick < < < Thin < < Passenger4 ≒ Passenger5 （Unicornは未調査。速いがPassengerに比して扱い難い。上級者向け） ９）通信経路の狭帯域対策 10M/bps → 1G/bps (ケーブル＋Switch機器を交換) Local Loopback は最速のNIC １０）通信装置の性能向上 Normal-HubをSwitchへ交換しコリジョンによる通信効率低下を回避
  • 120. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例２）【性能】リポジトリタブが遅い 120 【チューニング要素】 ・H/W: HDD, Memory, CPU ・S/W: DBMS, Ruby, WebAppServer, Subversion Server ・N/W: 通信帯域, Switching-Hub １）Subversionリポジトリの同期トリガを変更 SubversionとRedmine間のリポジトリ同期は、画面上のリポジトリタブをクリッ クすると実施されるのが既定の動作。リビジョン数が増えてくると表示されるまで に１分以上待たされる。 Redmine全体管理画面の「コミットを自動取得する」をOFFにして、Subversion リポジトリ側のPost-Commit-Hookに同期スクリプトを組み込むことで、同期ト リガが“コミット時”へ変更され、画面上のリポジトリタブは直ちに表示されるよう になる。 ２）Subversionリポジトリの同期対象を指定する 前述のPost-Commit-Hookは全プロジェクトを対象にするため、リポジトリ数が多 い場合5分以上かかる場合がある。ほぼ同時に5人が5回ずつコミットすると同期が 25並列で実行されてしまい、処理輻輳によりRedmineが応答しなくなる。 特定のProjectのみ同期を実施するよう、スクリプトに追記する。
  • 121. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例２）【性能】リポジトリタブが遅い 121 【チューニング要素】 ・H/W: HDD, Memory, CPU ・S/W: DBMS, Ruby, WebAppServer, Subversion Server ・N/W: 通信帯域, Switching-Hub ３）Subversionセッションキャッシュ セッション毎にキャッシュメモリを付与 （Subversion 1.7 以上） ４）Subversion通信圧縮機能 通信内容の圧縮レベル指定（Subversion 1.7 以上） ５）同一サーバーに置き、通信帯域を広くする Local loopback, TCP/UDP/Socket通信は高速 ６）MySQL テーブル更新が遅い DBMSメモリ設定 SSD採用
  • 122. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例３）【性能】検索が遅い 122 １）MySQLメモリチューニング ・メモリをできるだけ積み込む ・全インデックス、全データをオンメモリにする ２）カスタムフィールドの設定 「検索対象」の数が多いと極端に性能が落ちる 【チューニング要素】 ・H/W: Memory, CPU ・S/W: DBMS, Redmine
  • 123. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例４）【性能】画面応答が遅い 123 １）Rubyのバージョン 処理性能 1.9 < 2.0 < < < 2.1 < 2.2 < 2.3 << 2.4 ２）MySQLメモリチューニング 全インデックスと主要データをメモリに乗せる ３）初回アクセスが極端に遅い MySQL 5.6 – Bufferpool save and load PostgreSQL 9.4 - pg_prewarm ４）CPUコア数と同時並行処理数 処理要求が集中した時の待ち行列 CPUコアやHTスレッド数に合わせて並行度を上げ、最大待ち時間を低く抑える - Passenger：自動調整 （指定も可能） - Thin：起動サーバー数を増減 【チューニング要素】 ・H/W: HDD, Memory, CPU ・S/W: OS, DBMS, Http Server, Ruby, WebAppServer ・N/W: 通信帯域, Switching-Hub
  • 124. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例４）【性能】画面応答が遅い 124 ５）メール非同期送信（Async） 通知先が多い ／ メールサーバー（MTA）が遅い ６）Plugin導入数 導入数が多いと遅くなる。 大量データの応答性能まで考慮されているPluginはそう多くない。 ７）通信データの圧縮 HTTP1.1/Compression （最大10倍速） 【チューニング要素】 ・H/W: HDD, Memory, CPU ・S/W: OS, DBMS, Http Server, Ruby, WebAppServer ・N/W: 通信帯域, Switching-Hub
  • 125. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例５）【性能】特定プラグインが遅い 125 【チューニング要素】 ・H/W: Memory, CPU ・S/W: DBMS, Ruby, WebAppServer - 多くのプラグインは大量のデータ処理を想定していない。 極端に遅い場合はチューニングを施し、作者にパッチを送付できる。 処理遅延の原因は、SQL／コード実装／データ設計の３系統に大別できる。 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 ・アプリコード調査手順（今回は実施せず） ・データ設計調査手順 （今回は実施せず）
  • 126. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例６）【信頼性】不安定で手間がかかる 126 １）3歩遅れの「枯れた技術」 末尾が3になったら導入 例）Redmine 3.4.3 ２）Windows <<< Linux OS 両方面倒を見てきたが、Ruby, Rails はWindowsで制限が多い（印象） ３）RedmineUpdateの工夫 新旧の環境を並立させて動作を確認し、準備が整ったら切り替える ４）OSS パッチの取込み （Redmineに限って言えば）性能が改善され、問題は解消している。 Gitの追跡ブランチモードで git cloneしてLocal変更との共存を確保しつつ、 git pull だけでパッチを取りこめる。 例）mkdir /var/lib/its/rm34_its cd /var/lib/its/rm34_its git clone https://github.com/redmine/redmine.git . git checkout -b 3.4-stable-local origin/3.4-stable 【チューニング要素】 ・H/W: Memory, CPU ・S/W: DBMS, Ruby, WebAppServer
  • 127. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例６）【信頼性】不安定で手間がかかる 127 ５）Exception発生をMail 通知し、不具合を確実に検出 Redmine本体のExceptionは8年間でもほんの僅か ６）Redmine本体やRailsに手を入れない Redmine本体の品質は極めて高い テストコードのカバレッジ率がとても高い http://www.redmine.org/builds/coverage/ ７）Pluginは魅力的だが、あまり採用していない Redmine本体のUpdateの足枷になる テストコードが無く、DBテーブル構造を壊す例もある 【参考】 MTBF 8,820時間、MTTR 17時間、稼働率 99.8% 【チューニング要素】 ・H/W: Memory, CPU ・S/W: DBMS, Ruby, WebAppServer
  • 128. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例６）【信頼性】不安定で手間がかかる 128 ８）完全なクローン環境を常設 ・ゴミデータ、評価用データを本番に持ち込ませない ・要望を受けてから手動で同期 ・誤入力の事故を防止するため、画面の色を変えている 【チューニング要素】 ・H/W: Memory, CPU ・S/W: DBMS, Ruby, WebAppServer Dump and Restore
  • 129. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved Munin: Average latencyMunin: Average latency 事例７）【性能】電算機のH/W資源不足 129 １）1VMに集約し、狭帯域通信を回避 ２）CPU キャッシュの大きなものを複数コア用意 同時接続の処理数に合わせる ３）メモリ できるだけ積み込む ４）SSD導入： SSD（OS, DBMS, Redmine）、HDD（その他データ） ↓ SSD切替点↓ SSD切替点 【HDD】突出ピークが無くなった。【SSD】ピークが無くなりI/O waitが小さくなった。 振れ幅が小さく、余力が見てとれる。
  • 130. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例８）【性能】電算機通信網の帯域不足 130 ＜Network＞ １）主要通信経路は1G/bpsに統一 10M/bps, 100M/bps のボトルネックを排除 ２）Normal Hub → Switching Hub コリジョン発生率の低減 ３）Local Loopback通信 サーバー統合による通信の高速化
  • 131. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 事例９）【性能】起動が遅い 131 ＜DBMSの起動・再起動直後、初回アクセスだけが極端に遅い＞ １）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
  • 132. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 設定例１）基本S/W 132 OS, File-System １）OS CentOS 6 / 7 プロセス、パッケージは必要最低限に削ぎ落とす。 （パッチ適用、最少の停止頻度、セキュリティー、メモリ） ２）File-System Ext4 nobarrier チューン http://goo.gl/LYwfA0 ３）Kernel設定 ・[SSD] Disk I/O スケジューラーを cfq から deadline へ変更 ・[SSD] SWAP抑制 vm.swappiness=1 ※ 性能への影響は未確認
  • 133. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 設定例２）ミドルウェア 133 DBMS, WebServer, Web Application Server ＜DBMS＞ １）チューニング設定 ・MySQL 5.6 ２）SSDによるI/O改善 ・DBMS設定 MySQL innodb_flush_neighbors = 0 ・配置構成 DBデータだけでなく、OS全体をSSDに乗せると効果大 ・結果例 200万チケット分のDBデータをダンプ/リストア HDD → SSDにより33％向上（5分早く終わる）
  • 134. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 設定例２）ミドルウェア 134 DBMS, WebServer, Web Application Server ＜WebServer＞ ３）通信圧縮 Compress, Gzip, Deflate 圧縮 ＜Web Application Server＞ ４）選択 WEBLick は性能 × 運用の容易さは Unicorn < Passenger ５）Phusion Passenger 4 → 5 で 0.6％向上（計測の誤差範囲） ６）Passenger と OOBGC Passenger4, Ruby2.1, OOBGC(gctools)で安定稼働（実績１年） Passenger5, Ruby2.2, OOBGC(gctools)で安定稼働（実績6ヶ月） Passenger5, Ruby2.3, OOBGC(gctools)で安定稼働（実績１年） ７）Passenger Enterprise Multi Threadモードで○○％ 向上 (未調査) 利用料金は 5000円／月程度
  • 135. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 設定例３）応用S/W 135 Ruby, OOBGC, Redmine, Subversion ＜Ruby＞ ・GCの大幅改善によりRuby2.4が最速のバージョン ・2位は Ruby2.3＋OOBGC（調査時点 2017/07 ） ＜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.3, 2.4（Normal）が総合的に見て最適選択。 OOBGC有は最大性能への向上を必要とする方向け（ちょいムズ）
  • 136. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 設定例３）応用S/W 136 Ruby, OOBGC, Redmine, Subversion ＜Redmine＞ ・カスタムフィールドの設定値「検索条件」の数を減らす。 例「14万チケットだと30種 ○○秒 → 5種 〇秒」 （未計測だが効果は絶大） ・メール非同期送信(Async) config/configuration.yml production: email_delivery: delivery_method: :async_smtp async_smtp_settings:
  • 137. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 設定例３）応用S/W 137 Ruby, OOBGC, Redmine, Subversion ＜VCS＞ ・Subversion Server 1.7以降のセッションキャッシュ付与機能 セッションキャッシュにより、通信応答速度が向上する。 ・Subversion Server 1.7以降の通信圧縮機能 セッションデータ通信内容の多くはテキストデータ。 高い圧縮によって通信効率と応答性が向上する。
  • 138. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次 138 第１部 背景と要求 第２部 チューニングの基本 第３部 ベンチマーク 第４部 性能改善事例集 第５部 まとめ 第６部 付録 138
  • 139. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次 139 第１部 背景と要求 第２部 チューニングの基本 第３部 ベンチマーク 第４部 性能改善事例集 第５部 まとめ 第６部 付録 139
  • 140. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved お話ししたこと 140 １）200万チケットでもサクサク動くRedmineの全レシピ* ２）Redmine2.6 を 3.4 へUpdateすると平均で24.9％速くなる ３）Ruby2.0 を 2.4 へUpdateすると平均で26.9％速くなる ４）HDDをSSDに変更すると平均で18. 5％～25. 7％速くなる ５）非索引型の全文検索は10万チケットで性能限界に到達するが、 FTS-Pluginの導入によって約490倍速くなり、 200万チケットの環境で平均0.4～6秒で全文検索できる ６） Redmineチューニング事例 9種 *全レシピ： 設定値の一括ダウンロードはこちら (GitHub Gist) Download: Setting_paramaters_for_Redmine_Performance_Tuning.txt https://gist.github.com/akahane92/771f9a52d81af9864dd8
  • 141. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved まとめ｜実際 141 ・初期値のままでは、1万チケットまで ・最低限のチューニングで、5万チケットまで（Windows Bitnami） ・最低限のチューニングで、10万チケットまで（Linux,MySQL,Windowsスクラッチ） ・ある程度のチューニングで、200万チケットまで（Linux,MySQL） ・最大限のチューニング （必要としてないので今はやっていない） 処理並行度を上げる、高IOPsのDisk採用、DBMSのI/O最適化 例）Linux, MySQL： Nginx + Unicorn ロードバランサ ＋ WebAppServerクラスタリング ＋ DBMSクラスタリングと、R/W、R/Oの分離、SSD PCIe
  • 142. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved まとめ｜限界 143 RedmineのFTS (非索引型) （Redmineは悪くないが）10万チケットを超えた時点で検索が遅くなる。例 えばCPU４コアで稼働している時に、全プロジェクト横断の検索が４回ク リックされ、並行で実行されるとCPUが占有されてRedmineが無応答になっ てしまう。 → 今回、 Full Text Search Plugin による対処策が得られた。 十分な性能を確認できたことから、検索に関する懸念要素が払拭さ れた。 数十億文字を記録・蓄積している。何らかの索引型FTSをRedmine コアに標準機能として組み込んで欲しい。 検索できなくて困っているのは添付ファイル。先頃、良策がPlanioさ んから提供された。とても期待している。 ( Feature #306 Full Text Search of files )
  • 143. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次 144 第１部 背景と要求 第２部 チューニングの基本 第３部 ベンチマーク 第４部 性能改善事例集 第５部 まとめ 第６部 付録 144
  • 144. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 目次 145 第１部 背景と要求 第２部 チューニングの基本 第３部 ベンチマーク 第４部 性能改善事例集 第５部 まとめ 第６部 付録 145
  • 145. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録｜性能関連設定の一覧 146 本稿で扱った性能ベンチ－マークは下記設定による。 1. 計測プログラム 2. Apache2.2, 2.4 HTTP/1.1 通信圧縮 3. Passenger 4. MySQL 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
  • 146. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録｜計測方法 147 計測プログラム # bench.rb # -*- coding: utf-8 -*- url_list = [ "/its34 ", "/its34/projects ", "/its34/login ", "/its34/projects/sscope ", "/its34/issues?per_page=200 ", "/its34/issues/1 ", "/its34/issues/47548 ", "/its34/issues/51782 " ] puts "--- Environment ---" puts `httpd -version` puts `ruby -v` puts `gem list --local passenger` puts `export RAILS_ENV=production; /var/lib/its/rm32_its/bin/about` puts `export RAILS_ENV=production; /var/lib/its/rm32_its/bin/bundle list` ti = 5 result = [] url_list.each { |url| rate_avg = 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 "T ¥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)“ }
  • 147. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録｜Apache2.2, 2.4 148 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 通信圧縮
  • 148. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録｜Passenger 149 Apache2 /etc/httpd/conf.d/passenger.conf # Rails environment settings # RailsEnv production # Multiple Redmine Envirnoment with Sub-URI RailsBaseURI /its RailsBaseURI /its_practice # 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
  • 149. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録｜MySQL 5.6 150 ＜続き＞ 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
  • 150. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録｜MySQL 5.6 for Bitnami 151 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 #================================================================
  • 151. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録｜Subversion キャッシュ＆通信圧縮 152 Apache2.2, 2.4 /etc/httpd/conf.d/subversion.conf <IfModule dav_svn_module> SVNCompressionLevel 1 SVNInMemoryCacheSize 128000 SVNCacheFullTexts on SVNCacheTextDeltas on </IfModule>
  • 152. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録｜ Redmine Subversion同期 153 Subversion Post-Commit-Hook - post-commit #!/bin/sh # Redmine のプロジェクト名とSubversionリポジトリ名が一致している条件下でのスクリプト # 名称不一致の場合、本スクリプト中に名称を指定すればよい。（数が多いと面倒なのでお勧めしません） 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
  • 153. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録｜ Redmine OOBGC for Unicorn 154 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+
  • 154. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録｜ Redmine OOBGC for Passenger 155 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'
  • 155. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録｜ Redmine OOBGC for Passenger 156 ■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
  • 156. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録｜ Redmine OOBGC for Passenger 157 Passengerへの gctools導入 ■ /etc/httpd/conf.d/passenger.conf にOOBGC用の設定値を指定 # For OOBGC < Experimental > PassengerSpawnMethod direct
  • 157. Copyright (C) Shimadzu Business Systems Corporation. All Rights Reserved 付録｜OS File System 158 ■/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 注意：ディスクにアクセスできなくなったり、システム・アプリケーションが正しく動作しなくなる危険性があります。 バックアップを確保したうえで、理解できる方だけ自己責任でチャレンジしてください。 危険性が高いわりに、性能向上は体感しにくいので、専門家以外には推奨しません。

Editor's Notes

  • #2: 第8回 Redmine.tokyo 2015年5月16日
  • #3: 　「OSSは人類の資産です。これ無しでは何も出来なかった。 　　OSSを支えて下さっている皆様に深く感謝します。 　　たとえ小さなお手伝いであっても、自分にも出来る貢献をし続けたいと思っています。」
  • #8: Unix Like OSと、Windowsで80％
  • #9: Unix Like OSと、Windowsで80％
  • #10: Unix Like OSと、Windowsで80％
  • #17: 島津製作所 全世界で６８拠点、従業員１万人 業務システムの多くを引き受け、開発・運用を遂行 業務システムは長期間にわたって多くの変更を加えながら稼働する
  • #18: こういった製品を製造しています【2秒で次へ】
  • #19: 上場企業として、内部統制 ISOなどのマネジメントシステムを複数適用 主担当者として、6年間 関わってきました。
  • #20: 現場の負担が大きい 企業競争力への影響
  • #21: 記録を整合させ、精査・承認を行い、トレーサビリティーを確保 結果として、事業の目的合理性に沿った品質とセキュリティーを得る
  • #22: 多くの事案が入り乱れ、短期間で終わるもの、長期間にわたるもの、様々です。 システム連携は増加の一途にあります。 → 個々の事案について、詳しく見てみましょう。（次スライド）
  • #23: （読み上げ） 単純計算だが、10年で36万案件、20万コミットにも及ぶ。 これらの膨大な記録を、漏れなく保管しなければならない。 → この100システムは単独で稼働しているのではなく…（次スライド）
  • #24: （強調部分を主に読み上げ） 多くの現場が同様の課題に直面しているのではないでしょうか？ 実状に対して、高水準の要求が複数あります。現場が混乱する原因はここにあると私は考えています。 　 現象 ・　課題 1 　不確かで、消滅する 2 　再利用困難。作業コストが水泡に帰す 3 　検索できず、異動・離職で消滅 4 　共有不足で不具合、障害が増加 5 　経緯不明で後任の保守効率が低下 6 　モジュール間連携の影響探索に限界 過去経緯の不明が品質低下の温床 7 　業務効率の低下 8 　業務効率の低下、コストの上昇
  • #25: 全てを統合管理 ／ 組織に全面導入 ／ 解決経過と効果検証 ITSは本当に便利で、現場に役立つ仕組みです。同時に高水準の管理要求もこなします。 少しでも皆様のお役に立てたならば、京都から来た甲斐があります。
  • #26: （右図 タイトルのみ読上げ）
  • #29: 完了率は95％ チケット発行状況に比して、完了率の上昇が見られます。 有効な定着が得られたと考えます。
  • #30: 完了所要日数の平均は 　2011年の94日から 　2013年の44日へ半減しています。 長期滞留チケットの減少、管理手順の有効な定着、処理スループットの向上による効率化が得られました。
  • #31: その一方で、完了所要日数の平均が半減し、システム障害の処理効率化が実現しました。
  • #32: 特定システム１種のSpikeデータを除去すると、破線の折れ線グラフが示すとおり、密度の経年変化は維持傾向にあります。 この事実から、「障害・バグ」チケット件数の経年増加は、ITSと版数管理の利用徹底による、記録粒度の微細化によるものと考えています。
  • #33: 監査や認証対応の定量計測は行っていない。参考として実例を示す。 （読み上げる）
  • #34: 各要求に応えるため、管理手法を選んだ。 「一意識別→関連維持→追跡可能→信頼可能」 個人の利益を動機とする局所最適型 行動規範が、（結果として） 経営に資する知識管理システムとして、全体最適型 の均衡を得ていた。
  • #51: 2015年02月26日 中央大学理工学部 竹内健教授、SSDを従来比６倍高速化、５倍の高信頼化する技術をISSCCで発表
  • #54: IT統制、監査、査察 カスタマイズ、Pluginの動的Patch、の正当性をどうやって保証する？ 変更していないことをどうやって証明する？ 複数のPlugin間の干渉。予測、捕捉、対処は困難。
  • #67: 累計 1,216,420 アクセス （ [09/Nov/2009:08:48:59] ～ [03/Apr/2015:18:21:01]）
  • #68: 累計 1,216,420 アクセス （ [09/Nov/2009:08:48:59] ～ [03/Apr/2015:18:21:01]）
  • #70: Apacheアクセスログ1216万行は全て確保できていたが、 Production.logは途中からだけが残っている。
  • #78: 10万件の実データを元にして、データの質的分布が同じになるよう増やした。 　 【薄緑】　カスタムフィールドはチケットの増加と共に、大量のレコードを作り出すことが分かる。 【オレンジ】　注記欄もチケットの増加と共に大きく伸びる。
  • #79: 10万件の実データを元にして、データの質的分布が同じになるよう増やした。 　 【薄緑】　カスタムフィールドはチケットの増加と共に、大量のレコードを作り出すことが分かる。 【オレンジ】　注記欄もチケットの増加と共に大きく伸びる。
  • #86: OOBGCはちょいムズ。Ruby2.2.2を推奨
  • #93: Ruby2.2_OOBGC が最速だが、ちょいムズなのでRuby2.2をおすすめする。
  • #94: Ruby2.2_OOBGC が最速だが、ちょいムズなのでRuby2.2をおすすめする。
  • #95: Ruby OOBGC は10～13％程度の効果がある。 しかし、ちょいムズなのでRuby2.2系 OOBGC無を推奨したい。
  • #96: Ruby OOBGC は10～13％程度の効果がある。 しかし、ちょいムズなのでRuby2.2系 OOBGC無を推奨したい。
  • #97: Ruby OOBGC は10～13％程度の効果がある。 しかし、ちょいムズなのでRuby2.2系 OOBGC無を推奨したい。
  • #98: 各Redmineバージョンの最速ベンチマークを比較してみる。 電子計算機の能力向上が生じているため、比較精度は完全ではない。 2012年10月時点に計測したRedmine 2.3の頃に比べて、3.2は遅い。2.6はさらに遅い事がわかる。 Redmineの機能増加が、Rails、Redmine MT化、Ruby といった性能改善を食い尽くしたものと思われる。
  • #99: 各Redmineバージョンの最速ベンチマークを比較してみる。
  • #100: 各Redmineバージョンの最速ベンチマークを比較してみる。 電子計算機の能力向上が生じているため、比較精度は完全ではない。 2012年10月時点に計測したRedmine 2.3の頃に比べて、3.2は遅い。2.6はさらに遅い事がわかる。 Redmineの機能増加が、Rails、Redmine MT化、Ruby といった性能改善を食い尽くしたものと思われる。
  • #101: 各Redmineバージョンの最速ベンチマークを比較してみる。 電子計算機の能力向上が生じているため、比較精度は完全ではない。 2012年10月時点に計測したRedmine 2.3の頃に比べて、3.2は遅い。2.6はさらに遅い事がわかる。 Redmineの機能増加が、Rails、Redmine MT化、Ruby といった性能改善を食い尽くしたものと思われる。 Includes 192 Features / 294 Patches / 406 Defects
  • #108: HDDからSSDに交換すると、環境によって平均10.9％から25.7％の性能向上が得られる。 前回と今回のベンチマーク環境差 2016年3月　CentOS7　400GB SSD 　　10.9%　　　（SSDの性能を生かし切れていない可能性がある） 2015年5月　CentOS6　200GB SSD 　　25.7%
  • #109: HDDからSSDに交換すると、環境によって平均10.9％から25.7％の性能向上が得られる。 前回と今回のベンチマーク環境差 2016年3月　CentOS7　400GB SSD 　　10.9%　　　（SSDの性能を生かし切れていない可能性がある） 2015年5月　CentOS6　200GB SSD 　　25.7%
  • #110: 【問い】プラグインの有無が性能にどの程度の影響を与えるのか？ ■16種のプラグインを無作為に導入した。 　※ Redmine3.0対応となっていても動作しないものが８種あった 　※ 16種のプラグイン間の依存関係は調査していない。 　※ なぜプラグインを使用しないか。 　　・Redmineの土台であるRailsは進化が速い。 　　　Railsメジャーアップデートの際は動作しないRedmine Pluginが多発する。 　　　プラグインの豊かな機能を取るか、Redmineの進化・改善を優先するか。 　　　　→ 後者を選択 　　・モンキーパッチを行っていれば挙動は予想不可能。 　　・Redmine Hookのみを使用する”行儀の良い”プラグインであったとしても、 　　・起動や処理の順番もうまく制御できない仕組みなので、不安定要素となり得る。 　　　（相互依存や影響は誰もチェックしていないと思う）
  • #111: 　※ なぜプラグインを使用しないか。 　　・Redmineの土台であるRailsは進化が速い。 　　　Railsメジャーアップデートの際は動作しないRedmine Pluginが多発する。 　　　プラグインの豊かな機能を取るか、Redmineの進化・改善を優先するか。 　　　　　→ 後者を選択 　　・モンキーパッチを行っていれば挙動は予想不可能。 　　・Redmine Hookのみを使用する”行儀の良い”プラグインであったとしても、 　　・起動や処理の順番もうまく制御できない仕組みなので、不安定要素となり得る。 　　　（相互依存や影響は誰もチェックしていないと思う）
  • #112: 　※ なぜプラグインを使用しないか。 　　・Redmineの土台であるRailsは進化が速い。 　　　Railsメジャーアップデートの際は動作しないRedmine Pluginが多発する。 　　　プラグインの豊かな機能を取るか、Redmineの進化・改善を優先するか。 　　　　　→ 後者を選択 　　・モンキーパッチを行っていれば挙動は予想不可能。 　　・Redmine Hookのみを使用する”行儀の良い”プラグインであったとしても、 　　・起動や処理の順番もうまく制御できない仕組みなので、不安定要素となり得る。 　　　（相互依存や影響は誰もチェックしていないと思う） [kakahane@SMS03 rm30_its]$ ruby ./bin/about Environment: Redmine version 3.0.2.stable Ruby version 2.1.6-p336 (2015-04-13) [x86_64-linux] Rails version 4.2.1 Environment production Database adapter Mysql2 SCM: Subversion 1.7.14 Mercurial 1.4 Git 1.7.1 Filesystem Redmine plugins: clipboard_image_paste 1.10 redmine_banner 0.1.1 redmine_code_review 0.7.0 redmine_default_custom_query 1.1.0 redmine_emojibutton 0.3.0 redmine_importer 1.2.2 redmine_issue_templates 0.1.0 redmine_lightbox2 0.2.2 redmine_logs 0.1.0 redmine_my_page_queries 0.1.0 redmine_per_project_formatting 0.0.4 redmine_plugin_views_revisions 0.0.1 redmine_vividtone_my_page_blocks 1.2 (20120610) redmine_wiki_extensions 0.7.0 redmine_work_time 0.3.0 redmine_xls_export 0.2.1.t8
  • #113: 全走査 フルスキャン
  • #114: 全走査 フルスキャン
  • #115: ・SSDにしても効果があまり無かった 　→ DBMS上に記録された全走査処理のため、読込のDisk I/O処理が改善されると思ったが、I/O時間に比して、全走査処理の計算時間がとても大きいものだったため、数値に出るほどの変化は現れなかった。
  • #117: 主要画面７種の平均応答時間は、 987ms ÷ 7 = 141ms
  • #118: 主要画面７種の平均応答時間は、987ms ÷ 7 = 141ms 2015年5月時の調査（Redmine3.0）では、742ms ÷ 7 = 106ms
  • #119: 主要画面７種の平均応答時間は、 987ms ÷ 7 = 141ms
  • #137: MTBF　平均故障間隔 MTTR　平均修復時間
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy