Redmine + MySQL 応答性能の調査結果と対策
27 likes20,666 views
※ 最新版があります。こちら↓です ※「Redmineチューニングの実際と限界」 ※ http://www.slideshare.net/kakahane/redmine-48214015 MySQL勉強会 in 大阪#5_公開資料 日時： 2013/11/7 19:00～ 場所： 日本オラクル株式会社 西日本支社 参加： http://atnd.org/events/44157 主題：「事例発表：Redmine + MySQL 応答性能の調査結果と対策」 副題： ～ 200万チケット、画面応答100ms/req を想定したチュー ニング ～ 概要： ?ITS(Redmine)の全社適用後4年が経過した。チケット数 は10万を超え、その後も年間36,000件のペースで増加を 続けている。情報システム部門の業務システムとして 国内外へ活用範囲が拡大するなかで、応答性能の低下 対策が喫緊の課題となった。 ?100～200万チケットでの運用を想定し、(a)主要画面の 応答速度を100ms前後に収めつつ、(b)妥当な運用品質、 (c)安定性を確保するためにはどの様なチューニング? 技術が必要となるのかを検証した。 ?MySQL 5.6及び、電子計算機環境全域に対するチューニ ング法を調査?検討した結果、必要十分な性能を確保す る事ができたので、MySQLの利用事例としてコミュニ ティーにご紹介したい。
![Shimadzu Business Systems
5
１）応答性能低下の回避
Redmine ＋ MySQL5.6
200万チケット, 100ms/req
２）暖机运転の时间短缩
MySQL5.6 新機能
BufferPool 終了時Dump & 起動時Load
３）その他の対策
Ruby2.0, Passenger4 (OOBW-GC)
通信遅延回避
今日お話しすること
[*1]
[*3]
[*2]](https://image.slidesharecdn.com/mysqlosaka5-131112183844-phpapp02/85/Redmine-MySQL-5-320.jpg)
![Shimadzu Business Systems
12
背景 - 全てを統合
統合管理
全面導入
SVN
Mail
[*5]
チケットを
京大式カードの
延長線と考える
んや！ （想像）
[*4]](https://image.slidesharecdn.com/mysqlosaka5-131112183844-phpapp02/85/Redmine-MySQL-12-320.jpg)
![Shimadzu Business Systems
詳細（ご参考）
16
http://www.slideshare.net/kakahane/it-13718690
?IT全般統制
?ITS全社適用
?Excel脱却
?全体最適化
?10ルール
?主要画面応答
100ms以下
http://www.slideshare.net/kakahane/rx-tstudy6
http://www.slideshare.net/kakahane/3-d1-ja-sst13-kansai
[*6]](https://image.slidesharecdn.com/mysqlosaka5-131112183844-phpapp02/85/Redmine-MySQL-16-320.jpg)
![Shimadzu Business Systems
24
1. 応答性能低下の回避
?画面応答時間の基準とは？
参考文献
#1 Jakob Nielsen (1993). Response Times: The 3 Important Limits
http://www.useit.com/papers/responsetime.html
#2 Miller, R. B. (1968). Response time in man-computer conversational transactions.
http://theixdlibrary.com/pdf/Miller1968.pdf
100ms 直接操作している一体感
1000ms 遅延を感じつつも軽快
10000ms 集中限界、進捗表示必須
[*7]](https://image.slidesharecdn.com/mysqlosaka5-131112183844-phpapp02/85/Redmine-MySQL-24-320.jpg)
![Shimadzu Business Systems
25
1. 応答性能低下の回避
?画面応答時間の基準とは？
参考文献
#1 Jakob Nielsen (1993). Response Times: The 3 Important Limits
http://www.useit.com/papers/responsetime.html
#2 Miller, R. B. (1968). Response time in man-computer conversational transactions.
http://theixdlibrary.com/pdf/Miller1968.pdf
100ms 直接操作している一体感
1000ms 遅延を感じつつも軽快
10000ms 集中限界、進捗表示必須
ITSは「文房具」
[*7]](https://image.slidesharecdn.com/mysqlosaka5-131112183844-phpapp02/85/Redmine-MySQL-25-320.jpg)
![Shimadzu Business Systems
36
1. 応答性能低下の回避
MySQL 5.6.14
?初期値のままでは直ぐに１秒/req越
?MyNA発表資料「MySQL5.6パラ
メータ検討会」がとても参考になった。
http://d.hatena.ne.jp/sh2/20130806
?DBMS設定のチューニングは難しい。
(制限付きだが) 13項目に絞って計測。
[*8]](https://image.slidesharecdn.com/mysqlosaka5-131112183844-phpapp02/85/Redmine-MySQL-36-320.jpg)
![Shimadzu Business Systems
1. 応答性能低下の回避
[mysqld]
# InnoDB Paramaters
# http://dev.mysql.com/doc/refman/5.6/en/
innodb-parameters.html
innodb_buffer_pool_size = 8G
innodb_log_file_size = 2G
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
38
（参考値）](https://image.slidesharecdn.com/mysqlosaka5-131112183844-phpapp02/85/Redmine-MySQL-38-320.jpg)
Redmine + MySQL 応答性能の調査結果と対策
- 1. Shimadzu Business Systems 株式会社 島津ビジネスシステムズ 赤羽根 州晴 MySQL勉強会 in 大阪 #5 2013年11月7日 Copyright (c) Shimadzu Business Systems All Rights Reserved. Redmine + MySQL 応答性能の調査結果と対策 ～ 200万チケット、画面応答100ms/req を想定したチューニング～
- 3. ?赤羽根 州晴（＠akahane92） ?島津製作所 業務系システム子会社 → 開発技術者 Shimadzu Business Systems 話者紹介 → 障害対策専任 → 内部統制 → 基盤技術標準化 (現在) 3 参加団体 ?JaSST関西 ?RxTstudy ?AFFORDD 関西部会 ?京都アジャイル勉強会 ?WARAIテスト勉強会
- 5. Shimadzu Business Systems 5 １）応答性能低下の回避 Redmine ＋ MySQL5.6 200万チケット, 100ms/req ２）暖机运転の时间短缩 MySQL5.6 新機能 BufferPool 終了時Dump & 起動時Load ３）その他の対策 Ruby2.0, Passenger4 (OOBW-GC) 通信遅延回避 今日お話しすること [*1] [*3] [*2]
- 6. Shimadzu Business Systems 6 Redmine, MySQL 運用者は？ 教えてください！ 遅いと感じている方は？ 性能チューニングの ご経験者は？ → Redmine 60％ → MySQL 90％ → Redmine 20％ → 70％
- 8. Shimadzu Business Systems 8 島津製作所グループ （国内外拠点 ５７カ所） 背景
- 9. Shimadzu Business Systems 9 背景 - 課題管理モデル２ 課題 3 ～ 課題?要望 問合せ受付 調査と確認 状況報告 方針決定 対処と確認 結果報告 時間 課題 2 ～ トラブル 問合せ受付 調査と確認 状況報告 方針決定 対処と確認 結果報告 時間 課題 １ ～ タスク 問合せ受付 調査と確認 状況報告 方針決定 対処と確認 結果報告 時間 複数 ユーザー複数 ユーザー 複数の 国内外支社 ?販社 担当者 複数 ユーザー複数 ユーザー 複数の 国内外部門 ?担当者 N ： N ： N l Global Issue Tracking System
- 10. Shimadzu Business Systems 10 背景 - 運営状況 業務システム １０３種 利用者 7000人 案件36000 件 改版(コミット) 20500回 1783 KLOC 開発運用 ２００人 ／年 ／年 ／年 自動生成コード含む
- 11. Shimadzu Business Systems 11 背景 - 運営状況 BUSINESSMAN BURIED IN PAPERWORK --- IMAGE BY ? ROYALTY-FREE/CORBIS
- 12. Shimadzu Business Systems 12 背景 - 全てを統合 統合管理 全面導入 SVN Mail [*5] チケットを 京大式カードの 延長線と考える んや！ （想像） [*4]
- 13. Shimadzu Business Systems 13 背景 - 課題管理システムの全体像 Project A 問合せ 要望?課題 障害?バグ タスク Project B 問合せ 要望?課題 障害?バグ タスク 課題管理システ ム (ITS) 自動化ツール ビルド テスト リリース 構成管理ツール ?Subversion, CVS ?版数管理 （差分?結合?分派） （未着手） ■日常業務に浸透 ?トータルで負担減少 ?状態の掌握が容易 ?コミュニケーション促進 ■トレーサビリティー 一意性 永続的な 連鎖性 履歴追跡性 ■変化への適応 状況変化を記録し 追従する。後々の 参照が容易になる。
- 15. Shimadzu Business Systems 15 一意識別 ↓ 関連維持 ↓ 追跡可能 ↓ 信頼可能 個人の利益を動機とする 局所 最適型 行動規範が、(結果とし て) 経営に資する知識管理システ ムとして、全体最適型 の均衡を 得ていた。 IT全般統制 ISO ITIL FDA (Part 11) 省庁監査 【統制要求】 統制実現 コスト低減 属人性軽減 品質, CS向上 業績貢献 【経営要求】 現業務を表現可能なTool 入力コストに見合うTool ＜ユーザー体験＞ いつでも どこでも 素早く必ず見つかる 休みやすい 【現場の要求】 【管理手法】
- 17. Shimadzu Business Systems 詳細（ご参考） 17 http://www.slideshare.net/kakahane/it-13718690 ?IT全般統制 ?ITS全社適用 ?Excel脱却 ?全体最適化 ?10ルール ?主要画面応答 100ms以下 http://www.slideshare.net/kakahane/rx-tstudy6 http://www.slideshare.net/kakahane/3-d1-ja-sst13-kansai ユーザーコミュニティー ２０１３年１１月３０日 RxTstudy #９ ATND: http://atnd.org/events/45152
- 19. Shimadzu Business Systems 0 70 140 0 50000 100000 全チケット数 プロジェクト数 ITS現状 ? 計測 20112010 2012 98,000 Tickets 130 Projects 350 Users 19 2013 2013年11月7日時点
- 20. Shimadzu Business Systems ITS現状 ? 計測 0 50 100 0 50000 100000 2010 後 2011 前 2011 後 2012 前 2013前 2013後 全チケット数 １日平均発行数 完了率 20 Closed 92% 3000 Tickets/Month 20112010 2012 2013 2013年11月7日時点
- 21. Shimadzu Business Systems 1. 応答性能低下の回避 21
- 22. Shimadzu Business Systems 22 1. 応答性能低下の回避 ?ITSの業務活用が急拡大 ?チケット200万件まで確認 ?問題を洗い出した
- 24. Shimadzu Business Systems 24 1. 応答性能低下の回避 ?画面応答時間の基準とは？ 参考文献 #1 Jakob Nielsen (1993). Response Times: The 3 Important Limits http://www.useit.com/papers/responsetime.html #2 Miller, R. B. (1968). Response time in man-computer conversational transactions. http://theixdlibrary.com/pdf/Miller1968.pdf 100ms 直接操作している一体感 1000ms 遅延を感じつつも軽快 10000ms 集中限界、進捗表示必須 [*7]
- 25. Shimadzu Business Systems 25 1. 応答性能低下の回避 ?画面応答時間の基準とは？ 参考文献 #1 Jakob Nielsen (1993). Response Times: The 3 Important Limits http://www.useit.com/papers/responsetime.html #2 Miller, R. B. (1968). Response time in man-computer conversational transactions. http://theixdlibrary.com/pdf/Miller1968.pdf 100ms 直接操作している一体感 1000ms 遅延を感じつつも軽快 10000ms 集中限界、進捗表示必須 ITSは「文房具」 [*7]
- 26. Shimadzu Business Systems 26 1. 応答性能低下の回避 チューニング対象 Rails, Redmineを除く、 電子計算機全域が対象
- 28. Shimadzu Business Systems 28 1. 応答性能低下の回避 対策３種 ＃ 対象 対策 例 ① 通 信 狭帯域を回避 Ether Net ② 情報量 圧 縮 HTML JS ③ 電算処理 再処理を回避 CPU FileSystem DBMS
- 29. Shimadzu Business Systems 29 1. 応答性能低下の回避 対策① 狭帯域通信を避ける Auth ClientAPL DB MS SVN WebEthernet等 低速通信
- 30. Shimadzu Business Systems 30 1. 応答性能低下の回避 対策① 狭帯域通信を避ける Web DB MS Auth Client APL SVN 少数Serverへ集約 狭帯域６→３
- 31. Shimadzu Business Systems 31 1. 応答性能低下の回避 対策② 情報量の圧縮 Web DB MS Auth Client APL SVN Http/1.1 Compress ↓ 最大10倍速
- 32. Shimadzu Business Systems 32 1. 応答性能低下の回避 対策③ 再処理回避 Server Pass enger RAID OS FS NW Ruby Rails Redmine DBMS HTTP Reverse Proxy Client OS FS NW Browser JavaScript / DOM
- 33. Shimadzu Business Systems 33 1. 応答性能低下の回避 対策③ 再処理回避 Server Pass enger RAID OS FS NW Ruby Rails Redmine DBMS HTTP Reverse Proxy Client OS FS NW Browser JavaScript / DOM ?? ?? ? ? ? ? ? ? 潤沢なメモリ キャッシュ
- 34. Shimadzu Business Systems 34 1. 応答性能低下の回避 サーバー構成： 対象領域 Passenger4 OOBW GC RAID5 +20GB OS CentOS6 （64bit） Ruby 2.0.0 Rails3.2 Redmine2.3 DBMS MySQL 5.6 HTTP Apache 2.2 メモリ 4～16GBCPU 2～4コア VMware （運用円滑化） VCS Subversion 1.7 HTTP Reverse Proxy --- ：5 Key Point
- 35. Shimadzu Business Systems 35 1. 応答性能低下の回避 サーバー構成： 対象領域 Passenger4 OOBW GC RAID5 +20GB OS CentOS6 （64bit） Ruby 2.0.0 Rails3.2 Redmine2.3 DBMS MySQL 5.6 HTTP Apache 2.2 メモリ 4～16GBCPU 2～4コア VMware （運用円滑化） VCS Subversion 1.7 HTTP Reverse Proxy --- ：5 Key Pointcv詳説
- 36. Shimadzu Business Systems 36 1. 応答性能低下の回避 MySQL 5.6.14 ?初期値のままでは直ぐに１秒/req越 ?MyNA発表資料「MySQL5.6パラ メータ検討会」がとても参考になった。 http://d.hatena.ne.jp/sh2/20130806 ?DBMS設定のチューニングは難しい。 (制限付きだが) 13項目に絞って計測。 [*8]
- 37. Shimadzu Business Systems 37 1. 応答性能低下の回避 MySQL 5.6.14 注意！ ?変更前の my.cnf を確保 ?データベースのバックアップ確保 ?DBが起動しなくなる場合があります。 実施は自己責任でお願いします。 検証時の制限： ?Redmine, DBMS専用 仮想サーバー ?4コア ?メモリ 16GB ?MySQL 5.6.8以上 ?同時接続、処理数＝コア数 ?クラスタ分散無し
- 38. Shimadzu Business Systems 1. 応答性能低下の回避 [mysqld] # InnoDB Paramaters # http://dev.mysql.com/doc/refman/5.6/en/ innodb-parameters.html innodb_buffer_pool_size = 8G innodb_log_file_size = 2G 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 38 （参考値）
- 39. Shimadzu Business Systems 1. 応答性能低下の回避 １）innodb_buffer_pool_size = 1G ~ 8G →サーバー主メモリの40%~70%を設定 ２）innodb_log_file_size = 512M ~ 4G →上記１）の値の25%（~50%）を設定。 大きくしすぎるとリカバリに時間が かかる。また、この値を書き換える時 は要注意。 39 （参考値） 変化する値は２種に固定
- 41. Shimadzu Business Systems 41 このまま使い続けて大丈夫なのか？ 0 250,000 500,000 750,000 1,000,000 2013 2015 2020 2025 2030 チケット数 10万件の実データを複 写し、実際に２００万 件まで動作を確認した。 1. 応答性能低下の回避
- 42. Shimadzu Business Systems 42 現在 最大想定 チケット数 6万 200万 カスタムField値 63万 1200万 添付ファイル 3万 140万 時間記録 2万 74万 注記欄 14万 363万 Watcher 3万 76万 Ticket関係 1万 27万 1. 応答性能低下の回避
- 44. Shimadzu Business Systems ITSの耐用検証（応答基準） 44 0 ms 300 ms 600 ms 900 ms 1,200 ms 6万 10万 20万 30万 50万 70万 100万 150万 200万 Issue C Issue B Issue A Ticket List PJ Top PJ List ITS Top ※計測諸条件→巻末注記１ BP:4G LogFile:1G
- 45. Shimadzu Business Systems ITSの耐用検証（応答基準） 45 0 ms 300 ms 600 ms 900 ms 1,200 ms 6万 10万 20万 30万 50万 70万 100万 150万 200万 Issue C Issue B Issue A Ticket List PJ Top PJ List ITS Top 全文検索 20秒 対策必須 DB始動時の 暖機運転5分 2012年末リリースの MySQL 5.6に対策有り (巻末注記2-1) (BufferPool Dump/Restore) BufferPool 4GBでの結果 → 8GB必須 ※計測諸条件→巻末注記１
- 47. Shimadzu Business Systems ITSの耐用検証（応答基準） 47 0 ms 300 ms 600 ms 900 ms 1,200 ms 10万 20万 30万 50万 70万 100万 150万 200万 Issue C Issue B Issue A Ticket List PJ Top PJ List ITS Top ※計測諸条件→巻末注記１ BP:8G LogFile:2G
- 48. Shimadzu Business Systems ITSの耐用検証（応答基準） 48 0 ms 300 ms 600 ms 900 ms 1,200 ms 10万 20万 30万 50万 70万 100万 150万 200万 Issue C Issue B Issue A Ticket List PJ Top PJ List ITS Top ※計測諸条件→巻末注記１ 全文検索 20秒 対策必須 DB始動時の 暖機運転1~3分
- 49. Shimadzu Business Systems ２. 暖机运転の时间短缩 49
- 50. Shimadzu Business Systems 【口頭解説】 DBMSサーバーの再起動時の暖機運転が軽減される（Version 5.6） 暖機運転とは、DBMS再起動後にデータやインデックスをメモリ上へ読 み込ませる一連の処理。対象となるデータが増えると、長時間かかる こともある。 50 ２. 暖机运転の时间短缩
- 51. Shimadzu Business Systems 201３年1０月時点 BP:8G LogFile:２G 暖機運転に代わる BufferPool Dump&Load の効果 51 ２. 暖机运転の时间短缩
- 52. Shimadzu Business Systems ITSの耐用検証（応答基準） 52 0 ms 1,250 ms 2,500 ms 3,750 ms 5,000 ms 10万 20万 30万 50万 70万 100万 150万 200万 Issue C Issue B Issue A Ticket List PJ Top PJ List ITS Top ※計測諸条件→巻末注記１ 起動直後 BP Load：無
- 53. Shimadzu Business Systems ITSの耐用検証（応答基準） 53 0 ms 1,250 ms 2,500 ms 3,750 ms 5,000 ms 10万 20万 30万 50万 70万 100万 150万 200万 Issue C Issue B Issue A Ticket List PJ Top PJ List ITS Top ※計測諸条件→巻末注記１ 起動直後 BP Load：有
- 54. Shimadzu Business Systems ITSの耐用検証（応答基準） 54 0 ms 1,250 ms 2,500 ms 3,750 ms 5,000 ms 10万 20万 30万 50万 70万 100万 150万 200万 Issue C Issue B Issue A Ticket List PJ Top PJ List ITS Top ※計測諸条件→巻末注記１ 起動直後 BP Load：有 ２. 暖机运転の时间短缩 200万チケットの時は暖機運転に かなりの時間が必要だった。 MySQL5.6のBufferPool Dump&Load機能により、有効なペー ジキャッシュが短時間で回復していると 確認できた。
- 56. Shimadzu Business Systems 201３年1０月時点 BP:1 ～ 8G LogFile:512M～２G 暖機運転に代わる BP Dump&Load の効果 → BPサイズを変化させる 56 ２. 暖机运転の时间短缩
- 57. Shimadzu Business Systems 57 ２. 暖机运転の时间短缩
- 58. Shimadzu Business Systems 58 ２. 暖机运転の时间短缩 ２. 暖机运転の时间短缩 BufferPoolメモリを十分に積み込 めば新機能が効果を発揮し、暖機運 転の時間が短縮される。 しかしBufferPoolメモリが不十分 だと効果が薄れると確認。
- 60. Shimadzu Business Systems ３．その他対策 ?Ruby 2.0.0／1.9.3 ?Passenger4 OOBW-GC 有／無 ?(参考)Redmine バージョン間の比較 60
- 61. Shimadzu Business Systems ３．その他対策 【口頭解説】 RailsアプリケーションサーバーであるPassenger4は、遅延を軽減する OOBW（Out-of-Band Work）- GC(Garbage Collection)機能を実装実 現している。 Request処理中にRubyがGCすると処理遅延が生じるので「５回に１度だ け、Requestの間隙にGC」させる機能。 61
- 62. Shimadzu Business Systems 62 0 60 120 180 240 300 ITS Top PJ List PJ Top Ticket List Issue A Issue B Issue C Ruby1.9.3 Ruby2.0.0 OOBW-GC ※計測諸条件→巻末注記１ ３．その他対策
- 63. Shimadzu Business Systems 63 0 60 120 180 240 300 ITS Top PJ List PJ Top Ticket List Issue A Issue B Issue C Ruby1.9.3 Ruby2.0.0 OOBW-GC ※計測諸条件→巻末注記１ ３．その他対策 今回の計測環境 200万チケット、主要画面７種 結果 Ruby2.0.0 + Passenger4 OOBW- GCは、Ruby1.9.3 + Passenger4 に対し、画面６種において平均8.5%の 応答速度向上を確認した。
- 64. Shimadzu Business Systems ３．その他対策 (参考) Redmine バージョン間の比較 64
- 65. Shimadzu Business Systems 65 0 100 200 300 400 500 ITS Top PJ List PJ Top Ticket List Issue A Issue B Issue C Redmine 1.4 Redmine 2.0Tuned Redmine 2.1Tuned Redmine 2.3Tuned ※計測諸条件→巻末注記１ 10万チケット Redmine 各バージョンの比較 ３．その他対策
- 67. Shimadzu Business Systems 67 MySQL5.6 の改善 ?Redmine2.0→2.3の機能追 加を吸収しつつも性能の劣化が少 ない。 ?十分なメモリを与えれば、暖機 運転も妥当な運用レベルに収束す ると確認できた。 まとめ２
- 68. Shimadzu Business Systems 68 Ruby2.0, Passenger4 OOBW-GCによる改善 ?平均8.5％の応答時間向上 まとめ３
- 69. Shimadzu Business Systems 69 ■応答時間の計測条件（詳細） １）評価サーバー 計算機環境 VM 1台 (CPU Xeon 3GHz x4 Cores, Memory 8GB, Storage iSCSI-1G 150GB) on VMware ESXi ※ 評価用サーバーを単独使用。よって外部からの影響要素は無視できる。 ２）ソフトウェア構成 Redmine 2.3.3 本体改変無し、Plug-in無し ?CentOS6.4(x64), Apache2, Ruby1.9.3, Passenger4, Rails3.2, MySQL5.6.14 +（設定値 13種） ?CentOS6.4(x64), Apache2, Ruby2.0.0, Passenger4, Rails3.2, MySQL5.6.14 +（設定値 13種） ３）評価対象 ７画面 (1) Redmine Top 画面 (5) Issue A - Light (2) Project 一覧画面 (6) Issue B - Heavy (3) Project Top 画面（150Users） (7) Issue C - Regular (4) Ticket List （200件 / 10000件表示） ４）評価方法 httperf http://www.hpl.hp.com/research/linux/httperf/ (下記コマンドをサーバー上で１０回実行し、平均する) httperf --hog --server=localhost --port=80 --uri=/its --num-conns 2 --num-calls 25 httperf --hog --server=localhost --port=80 --uri=/its/projects --num-conns 2 --num-calls 25 httperf --hog --server=localhost --port=80 --uri=/its/projects/sscope --num-conns 2 --num-calls 25 httperf --hog --server=localhost --port=80 --uri=/its/issues?per_page=200 --num-conns 2 --num-calls 25 httperf --hog --server=localhost --port=80 --uri=/its/issues/1 --num-conns 2 --num-calls 25 httperf --hog --server=localhost --port=80 --uri=/its/issues/47548 --num-conns 2 --num-calls 25 httperf --hog --server=localhost --port=80 --uri=/its/issues/51782 --num-conns 2 --num-calls 25 巻末注記１
- 70. Shimadzu Business Systems 70 参考文献 1.Redmine / OpenSource Software / Jean-Philippe Lang http://www.redmine.org/ 2.MySQL 5.6 Bu?erPool Dump and Load? http://dev.mysql.com/doc/refman/5.6/en/innodb-performance.html ? 14.2.13.2.8. Faster Restart by Preloading the InnoDB Bu?er Pool 3.Passenger OOBW-GC http://blog.phusion.nl/2013/01/22/phusion-passenger-4-technology-preview- out-of-band-work/ 4.知的生産の技術 / 岩波新書 / 梅棹忠夫, 1969 5.Redmineによるタスクマネジメント技法 / 翔泳社 / 小川明彦, 阪井誠, 2010 6.過去の発表資料 ?情報システム部門のタスク管理とIT全般統制 ～ Excel管理からの脱却 ～ (ITS Redmine #RxTstudy #5) http://www.slideshare.net/kakahane/it-13718690 ?情報システム部門のタスク管理~ITS応答性能の調査結果と対策 編~ http://www.slideshare.net/kakahane/rx-tstudy6 ?ソフトウェアの品質向上に資する、開発?運用現場の情報管理 http://www.slideshare.net/kakahane/3-d1-ja-sst13-kansai 7. #1 Jakob Nielsen (1993). Response Times: The 3 Important Limits http://www.useit.com/papers/responsetime.html #2 Miller, R. B. (1968). Response time in man-computer conversational transactions. http://theixdlibrary.com/pdf/Miller1968.pdf 8. MyNA発表資料「MySQL5.6パラメータ検討会」 http://d.hatena.ne.jp/sh2/20130806