Redmine + MySQL 応答性能の調査結果と対策

15,428 views

Published on

※ 最新版があります。こちら↓です
※「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の利用事例としてコミュニ
   ティーにご紹介したい。

Published in: Technology

Redmine + MySQL 応答性能の調査結果と対策

  1. 1. Shimadzu Business Systems 株式会社 島津ビジネスシステムズ 赤羽根 州晴 MySQL勉強会 in 大阪 #5 2013年11月7日 Copyright (c) Shimadzu Business Systems All Rights Reserved. Redmine + MySQL 応答性能の調査結果と対策 ~ 200万チケット、画面応答100ms/req を想定したチューニング~
  2. 2. ※最新情報を反映したスライドをUploadしました。以下のURLをご参照ください。 Redmineチューニングの実際と限界 (2016-03) http://www.slideshare.net/kakahane/redmine-48214015 旧資料(2012-10) 情報システム部門のタスク管理管理 ~ITS応答性能の調査結果と対策~ http://www.slideshare.net/kakahane/rx-tstudy6
  3. 3. ・赤羽根 州晴(@akahane92) ・島津製作所 業務系システム子会社  → 開発技術者   Shimadzu Business Systems 話者紹介   → 障害対策専任   → 内部統制    → 基盤技術標準化 (現在) 3 参加団体 ・JaSST関西 ・RxTstudy ・AFFORDD 関西部会 ・京都アジャイル勉強会 ・WARAIテスト勉強会
  4. 4. Shimadzu Business Systems 4 ありがとう。
  5. 5. Shimadzu Business Systems 5 1)応答性能低下の回避       Redmine + MySQL5.6       200万チケット, 100ms/req 2)暖機運転の時間短縮       MySQL5.6 新機能       BufferPool 終了時Dump & 起動時Load 3)その他の対策       Ruby2.0, Passenger4 (OOBW-GC)       通信遅延回避 今日お話しすること [*1] [*3] [*2]
  6. 6. Shimadzu Business Systems 6 Redmine, MySQL 運用者は? 教えてください! 遅いと感じている方は? 性能チューニングの ご経験者は? → Redmine 60% → MySQL 90% → Redmine 20% → 70%
  7. 7. Shimadzu Business Systems 7 背景紹介 (簡単に)
  8. 8. Shimadzu Business Systems 8 島津製作所グループ  (国内外拠点 57カ所) 背景
  9. 9. Shimadzu Business Systems 9 背景 - 課題管理モデル2  課題 3 ~ 課題・要望 問合せ受付 調査と確認 状況報告 方針決定 対処と確認 結果報告 時間  課題 2 ~ トラブル 問合せ受付 調査と確認 状況報告 方針決定 対処と確認 結果報告 時間  課題 1 ~ タスク 問合せ受付 調査と確認 状況報告 方針決定 対処と確認 結果報告 時間 複数 ユーザー複数 ユーザー 複数の 国内外支社 ・販社 担当者 複数 ユーザー複数 ユーザー 複数の 国内外部門 ・担当者 N  :  N  :  N l Global Issue Tracking System
  10. 10. Shimadzu Business Systems 10 背景 - 運営状況 業務システム 103種 利用者 7000人 案件36000 件 改版(コミット) 20500回 1783 KLOC 開発運用 200人 /年 /年 /年 自動生成コード含む
  11. 11. Shimadzu Business Systems 11 背景 - 運営状況 BUSINESSMAN BURIED IN PAPERWORK --- IMAGE BY © ROYALTY-FREE/CORBIS
  12. 12. Shimadzu Business Systems 12 背景 - 全てを統合 統合管理 全面導入 SVN Mail [*5] チケットを 京大式カードの 延長線と考える んや! (想像) [*4]
  13. 13. Shimadzu Business Systems 13 背景 - 課題管理システムの全体像 Project A 問合せ 要望・課題 障害・バグ タスク Project B 問合せ 要望・課題 障害・バグ タスク 課題管理システ ム (ITS) 自動化ツール ビルド テスト リリース 構成管理ツール •Subversion, CVS •版数管理 (差分・結合・分派) (未着手) ■日常業務に浸透 •トータルで負担減少 •状態の掌握が容易 •コミュニケーション促進 ■トレーサビリティー        一意性 永続的な   連鎖性        履歴追跡性 ■変化への適応  状況変化を記録し  追従する。後々の  参照が容易になる。
  14. 14. Shimadzu Business Systems 14 (チケット実物)
  15. 15. Shimadzu Business Systems 15 一意識別 ↓ 関連維持 ↓ 追跡可能 ↓ 信頼可能 個人の利益を動機とする 局所 最適型 行動規範が、(結果とし て) 経営に資する知識管理システ ムとして、全体最適型 の均衡を 得ていた。  IT全般統制  ISO  ITIL  FDA (Part 11)  省庁監査 【統制要求】  統制実現  コスト低減  属人性軽減  品質, CS向上  業績貢献 【経営要求】  現業務を表現可能なTool  入力コストに見合うTool  <ユーザー体験>   いつでも どこでも   素早く必ず見つかる   休みやすい 【現場の要求】   【管理手法】
  16. 16. 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]
  17. 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 ユーザーコミュニティー 2013年11月30日 RxTstudy #9 ATND: http://atnd.org/events/45152
  18. 18. Shimadzu Business Systems 18 現 状
  19. 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. 20. Shimadzu Business Systems ITS現状 ー 計測 0 50 100 0 50000 100000 2010 後 2011 前 2011 後 2012 前 2013前 2013後 全チケット数 1日平均発行数 完了率 20 Closed 92% 3000 Tickets/Month 20112010 2012 2013 2013年11月7日時点
  21. 21. Shimadzu Business Systems 1. 応答性能低下の回避 21
  22. 22. Shimadzu Business Systems 22 1. 応答性能低下の回避 ・ITSの業務活用が急拡大 ・チケット200万件まで確認 ・問題を洗い出した
  23. 23. Shimadzu Business Systems 23 基 準
  24. 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. 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. 26. Shimadzu Business Systems 26 1. 応答性能低下の回避 チューニング対象  Rails, Redmineを除く、  電子計算機全域が対象
  27. 27. Shimadzu Business Systems 27 対 策
  28. 28. Shimadzu Business Systems 28 1. 応答性能低下の回避  対策3種 # 対象 対策 例 ① 通 信 狭帯域を回避 Ether Net ② 情報量 圧 縮 HTML JS ③ 電算処理 再処理を回避 CPU FileSystem DBMS
  29. 29. Shimadzu Business Systems 29 1. 応答性能低下の回避  対策① 狭帯域通信を避ける Auth ClientAPL DB MS SVN WebEthernet等 低速通信
  30. 30. Shimadzu Business Systems 30 1. 応答性能低下の回避  対策① 狭帯域通信を避ける Web DB MS Auth Client APL SVN 少数Serverへ集約 狭帯域6→3
  31. 31. Shimadzu Business Systems 31 1. 応答性能低下の回避  対策② 情報量の圧縮 Web DB MS Auth Client APL SVN Http/1.1 Compress ↓ 最大10倍速
  32. 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. 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. 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. 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. 36. Shimadzu Business Systems 36 1. 応答性能低下の回避  MySQL 5.6.14 ・初期値のままでは直ぐに1秒/req越   ・MyNA発表資料「MySQL5.6パラ  メータ検討会」がとても参考になった。   http://d.hatena.ne.jp/sh2/20130806   ・DBMS設定のチューニングは難しい。  (制限付きだが) 13項目に絞って計測。 [*8]
  37. 37. Shimadzu Business Systems 37 1. 応答性能低下の回避  MySQL 5.6.14 注意! ・変更前の my.cnf を確保     ・データベースのバックアップ確保     ・DBが起動しなくなる場合があります。      実施は自己責任でお願いします。 検証時の制限:  ・Redmine, DBMS専用 仮想サーバー  ・4コア  ・メモリ 16GB  ・MySQL 5.6.8以上  ・同時接続、処理数=コア数  ・クラスタ分散無し
  38. 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. 39. Shimadzu Business Systems 1. 応答性能低下の回避 1)innodb_buffer_pool_size = 1G ~ 8G    →サーバー主メモリの40%~70%を設定 2)innodb_log_file_size = 512M ~ 4G    →上記1)の値の25%(~50%)を設定。     大きくしすぎるとリカバリに時間が     かかる。また、この値を書き換える時     は要注意。 39  (参考値) 変化する値は2種に固定
  40. 40. Shimadzu Business Systems ITSの耐用検証(応答基準) 40
  41. 41. Shimadzu Business Systems 41 このまま使い続けて大丈夫なのか? 0 250,000 500,000 750,000 1,000,000 2013 2015 2020 2025 2030 チケット数 10万件の実データを複 写し、実際に200万 件まで動作を確認した。 1. 応答性能低下の回避
  42. 42. Shimadzu Business Systems 42 現在 最大想定 チケット数 6万 200万 カスタムField値 63万 1200万 添付ファイル 3万 140万 時間記録 2万 74万 注記欄 14万 363万 Watcher 3万 76万 Ticket関係 1万 27万 1. 応答性能低下の回避
  43. 43. Shimadzu Business Systems 2012年10月時点の ベンチマークと課題 43
  44. 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 ※計測諸条件→巻末注記1 BP:4G LogFile:1G
  45. 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必須 ※計測諸条件→巻末注記1
  46. 46. Shimadzu Business Systems 2013年10月時点の ベンチマークと課題 46
  47. 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 ※計測諸条件→巻末注記1 BP:8G LogFile:2G
  48. 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 ※計測諸条件→巻末注記1 全文検索 20秒 対策必須 DB始動時の 暖機運転1~3分
  49. 49. Shimadzu Business Systems 2. 暖機運転の時間短縮 49
  50. 50. Shimadzu Business Systems 【口頭解説】 DBMSサーバーの再起動時の暖機運転が軽減される(Version 5.6) 暖機運転とは、DBMS再起動後にデータやインデックスをメモリ上へ読 み込ませる一連の処理。対象となるデータが増えると、長時間かかる こともある。   50 2. 暖機運転の時間短縮
  51. 51. Shimadzu Business Systems 2013年10月時点  BP:8G  LogFile:2G 暖機運転に代わる BufferPool Dump&Load の効果 51 2. 暖機運転の時間短縮
  52. 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 ※計測諸条件→巻末注記1 起動直後 BP Load:無
  53. 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 ※計測諸条件→巻末注記1 起動直後 BP Load:有
  54. 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 ※計測諸条件→巻末注記1 起動直後 BP Load:有 2. 暖機運転の時間短縮 200万チケットの時は暖機運転に かなりの時間が必要だった。 MySQL5.6のBufferPool Dump&Load機能により、有効なペー ジキャッシュが短時間で回復していると 確認できた。
  55. 55. Shimadzu Business Systems ITSの耐用検証(応答基準) 55 BufferPool Dump&Load機能と、 メモリ割当て量の関係
  56. 56. Shimadzu Business Systems 2013年10月時点  BP:1 ~ 8G  LogFile:512M~2G 暖機運転に代わる BP Dump&Load の効果 → BPサイズを変化させる 56 2. 暖機運転の時間短縮
  57. 57. Shimadzu Business Systems 57 2. 暖機運転の時間短縮
  58. 58. Shimadzu Business Systems 58 2. 暖機運転の時間短縮 2. 暖機運転の時間短縮 BufferPoolメモリを十分に積み込 めば新機能が効果を発揮し、暖機運 転の時間が短縮される。 しかしBufferPoolメモリが不十分 だと効果が薄れると確認。
  59. 59. Shimadzu Business Systems 3.その他対策 59
  60. 60. Shimadzu Business Systems 3.その他対策 ・Ruby 2.0.0/1.9.3 ・Passenger4 OOBW-GC  有/無 ・(参考)Redmine バージョン間の比較 60
  61. 61. Shimadzu Business Systems 3.その他対策 【口頭解説】 RailsアプリケーションサーバーであるPassenger4は、遅延を軽減する OOBW(Out-of-Band Work)- GC(Garbage Collection)機能を実装実 現している。 Request処理中にRubyがGCすると処理遅延が生じるので「5回に1度だ け、Requestの間隙にGC」させる機能。 61
  62. 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 ※計測諸条件→巻末注記1 3.その他対策
  63. 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 ※計測諸条件→巻末注記1 3.その他対策 今回の計測環境 200万チケット、主要画面7種 結果 Ruby2.0.0 + Passenger4 OOBW- GCは、Ruby1.9.3 + Passenger4 に対し、画面6種において平均8.5%の 応答速度向上を確認した。
  64. 64. Shimadzu Business Systems 3.その他対策 (参考)  Redmine バージョン間の比較 64
  65. 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 ※計測諸条件→巻末注記1 10万チケット Redmine 各バージョンの比較 3.その他対策
  66. 66. Shimadzu Business Systems 66 ITSと連動した全文検索の解決策 と、16GBのメモリがあれば 200万チケットの運用に於いても 日常的に使用する画面・機能にお いて100ms前後の応答性能を Redmine2.3系で期待できる。 まとめ1
  67. 67. Shimadzu Business Systems 67 MySQL5.6 の改善 ・Redmine2.0→2.3の機能追 加を吸収しつつも性能の劣化が少 ない。 ・十分なメモリを与えれば、暖機 運転も妥当な運用レベルに収束す ると確認できた。 まとめ2
  68. 68. Shimadzu Business Systems 68 Ruby2.0, Passenger4 OOBW-GCによる改善 ・平均8.5%の応答時間向上 まとめ3
  69. 69. Shimadzu Business Systems 69 ■応答時間の計測条件(詳細)  1)評価サーバー    計算機環境 VM 1台 (CPU Xeon 3GHz x4 Cores, Memory 8GB, Storage iSCSI-1G 150GB) on VMware ESXi     ※ 評価用サーバーを単独使用。よって外部からの影響要素は無視できる。  2)ソフトウェア構成    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種)  3)評価対象 7画面    (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件表示)  4)評価方法   httperf http://www.hpl.hp.com/research/linux/httperf/ (下記コマンドをサーバー上で10回実行し、平均する) 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 巻末注記1
  70. 70. Shimadzu Business Systems 70 参考文献 1.Redmine / OpenSource Software / Jean-Philippe Lang   http://www.redmine.org/ 2.MySQL 5.6 BufferPool 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 Buffer 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
  71. 71. Shimadzu Business Systems ご清聴 ありがとう ございました
  72. 72. 協 力 島津ビジネスシステムズ 72
  73. 73. Shimadzu Business Systems 島津製作所のご紹介    島津製作所グループ   事業領域    ・分析計測    ・医用機器    ・航空機器    ・半導体機器    ・油圧, 光学 73

×