Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
秒間1800リクエストの世界 / The world of 1800 reqs per sec
Search
HASEGAWA Tomoki
June 10, 2017
Programming
5
5.9k
秒間1800リクエストの世界 / The world of 1800 reqs per sec
PHPカンファレンス福岡2017の資料です
HASEGAWA Tomoki
June 10, 2017
Tweet
Share
More Decks by HASEGAWA Tomoki
See All by HASEGAWA Tomoki
PHPからはじめるコンピュータアーキテクチャ / From Scripts to Silicon: A Journey Through the Layers of Computing
tomzoh
4
460
低レイヤを知りたいPHPerのためのCコンパイラ作成入門 完全版 / Building a C Compiler for PHPers Who Want to Dive into Low-Level Programming - Expanded
tomzoh
6
3.7k
カンファレンスのつくりかた / The Conference Code: What Makes It All Work
tomzoh
9
1.7k
低レイヤを知りたいPHPerのためのCコンパイラ作成入門 / Building a C Compiler for PHPers Who Want to Dive into Low-Level Programming
tomzoh
1
640
PHPで印刷所に入稿できる名札データを作る / Generating Print-Ready Name Tag Data with PHP
tomzoh
0
600
asumikamというカンファレンスオーガナイザの凄さを語る / The Brilliance of Asumikam
tomzoh
1
510
なぜキャッシュメモリは速いのか 余談集 / Why is Cache Memory So Fast? Extended.
tomzoh
0
290
なぜキャッシュメモリは速いのか / Why is Cache Memory So Fast?
tomzoh
3
1.6k
PHPからはじめるコンピュータアーキテクチャ 15分ダイジェスト版 / PHP Meets Silicon: A Fun Dive into Computer Structures 15mins ver
tomzoh
2
330
Other Decks in Programming
See All in Programming
生成AI、実際どう? - ニーリーの場合
nealle
0
110
A Gopher's Guide to Vibe Coding
danicat
0
160
あまり知られていない MCP 仕様たち / MCP specifications that aren’t widely known
ktr_0731
0
280
The State of Fluid (2025)
s2b
0
170
『リコリス・リコイル』に学ぶ!! 〜キャリア戦略における計画的偶発性理論と変わる勇気の重要性〜
wanko_it
1
540
管你要 trace 什麼、bpftrace 用下去就對了 — COSCUP 2025
shunghsiyu
0
420
書き捨てではなく継続開発可能なコードをAIコーディングエージェントで書くために意識していること
shuyakinjo
1
280
プロダクトという一杯を作る - プロダクトチームが味の責任を持つまでの煮込み奮闘記
hiliteeternal
0
460
Comparing decimals in Swift Testing
417_72ki
0
170
AI時代のドメイン駆動設計-DDD実践におけるAI活用のあり方 / ddd-in-ai-era
minodriven
21
8k
Constant integer division faster than compiler-generated code
herumi
2
670
Webinar: AI-Powered Development: Transformiere deinen Workflow mit Coding Tools und MCP Servern
danielsogl
0
130
Featured
See All Featured
Embracing the Ebb and Flow
colly
86
4.8k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.5k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
183
54k
How to Ace a Technical Interview
jacobian
279
23k
Statistics for Hackers
jakevdp
799
220k
Side Projects
sachag
455
43k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Code Reviewing Like a Champion
maltzj
525
40k
Being A Developer After 40
akosma
90
590k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
21k
The Straight Up "How To Draw Better" Workshop
denniskardys
236
140k
Transcript
1,800リクエスト/秒の世界 The world of 1,800 requests / sec 長谷川智希 HASEGAWA
Tomoki
長谷川 智希 デジタルサーカス株式会社 副団長CTO Digital Circus, Inc. Vice-master CTO Tokyo,
Japan @tomzoh
ライフワーク: Web / iOSアプリ開発, ビール, 電子工作, サッカー観戦, レンタルカートレース, … 長谷川
智希 Web / iOS App Development, Beer, IoT, Watch soccer match, Rental Kart Racing, … デジタルサーカス株式会社 副団長CTO Digital Circus, Inc. Vice-master CTO Tokyo, Japan Lifeworks: @tomzoh
None
None
WE ARE HIRING!! Web Development Mobile App Development ( )
(iOS, Android) http://www.dgcircus.com Omotesando, Tokyo
今日のテーマ The world of 1,800 requests / sec 1,800リクエスト/秒の世界 Today’s
theme
システム概要
今回の対象システム • Web + API + iOS/Android アプリ • 就職活動関連アプリ
• ユーザ数: 100万前後
今回の対象システム • Web + API + iOS/Android アプリ • 就職活動関連アプリ
• ユーザ数: 100万前後
システム構成 Ȑ Ȑ 2 × m4.large vCPU: 2 / memory:
8GB EC2 RDS db.m3.xlarge vCPU: 4 / memory: 7.5GB iOS / Android Mobile Apps 1,000,000users
技術スタック
技術スタック 今日の話
負荷がやってくる
なぜわかっている?
03/01 0:00 就職活動解禁
負荷 • 負荷がやってくる
負荷 • 負荷がやってくる • 耐えられる様にしたい • 負荷を想定 • 耐えられそうな仮構成を作る •
負荷を作り出して構成を調整
負荷 • 負荷がやってくる • 耐えられる様にしたい • 負荷を想定 • 耐えられそうな仮構成を作る •
負荷を作り出して構成を調整 • どうやって耐えるか • Webサーバ(EC2)のスケールアウトで対応したい • DB(RDS)がツラければスケールアップする
• 耐えられる様にしたい • 負荷を想定 • 耐えられそうな仮構成を作る • 負荷を作り出して構成を調整 負荷 •
負荷がやってくる • どうやって耐えるか • Webサーバ(EC2)のスケールアウトで対応したい • DB(RDS)がツラければスケールアップする
負荷の計算に使える材料
負荷の計算 • 負荷の計算に使える素材 • サイト全体のWebでのページビュー/秒 • ネイティブアプリのユーザ比率
負荷の計算 • 負荷の計算に使える素材 • サイト全体のWebでのページビュー/秒 • ネイティブアプリのユーザ比率 10,000PV/sec
負荷の計算 • 負荷の計算に使える素材 • サイト全体のWebでのページビュー/秒 • ネイティブアプリのユーザ比率 10,000PV/sec 30%
負荷の計算 • 負荷の計算に使える素材 • サイト全体のWebでのページビュー/秒 • ネイティブアプリのユーザ比率 10,000PV/sec 30% ×
\3,000 PV/sec /
\3,000 PV/sec / ざわ... ざわ...
まあ待て
落ち着け
Ȑ
Ȑ API
PV APIコール
PV APIコール ≠
PV APIコール ≠ 変換
PV → API • ユーザがどういう行動を取るか • シナリオを作成 • シナリオの各ステップで発生するAPIコールをリストアップ •
シナリオの各ステップから、同じ動作をWebで実施した場合 に発生するPVに変換 • PV → APIコールの変換ができる
シナリオ No. 操作 ユーザ 操作 処理 時間 仮想 PV 1
アプリ初回起動 1 2 ログイン画面からのログイン処理 10 1 2 3 ホーム表示 2 1 1 4 検索タブ表示 2 1 5 検索 10 2 3 6 検索結果一覧画面表示 1 7 (詳細画面 → エントリー)x 30 3,000 120 120
シナリオとその割合 シナリオ ユーザ 操作 処理 時間 仮想 PV 創出 PV/秒
シナリオ 割合 必要 PV/秒 同時セッシ ョン シナリオ1 3,022 127 128 0.04 20% 600 14,761 シナリオ2 27 10 8 0.22 40% 1,200 5,550 シナリオ3 21 11 5 0.16 35% 1,050 6,720 シナリオ4 20 10 12 0.40 5% 150 375
シナリオとその割合 シナリオ ユーザ 操作 処理 時間 仮想 PV 創出 PV/秒
シナリオ 割合 必要 PV/秒 同時セッシ ョン シナリオ1 3,022 127 128 0.04 20% 600 14,761 シナリオ2 27 10 8 0.22 40% 1,200 5,550 シナリオ3 21 11 5 0.16 35% 1,050 6,720 シナリオ4 20 10 12 0.40 5% 150 375 3,000PV/sec
シナリオとその割合 シナリオ ユーザ 操作 処理 時間 仮想 PV 創出 PV/秒
シナリオ 割合 必要 PV/秒 同時セッシ ョン シナリオ1 3,022 127 128 0.04 20% 600 14,761 シナリオ2 27 10 8 0.22 40% 1,200 5,550 シナリオ3 21 11 5 0.16 35% 1,050 6,720 シナリオ4 20 10 12 0.40 5% 150 375 3,000PV/sec
シナリオとその割合 シナリオ ユーザ 操作 処理 時間 仮想 PV 創出 PV/秒
シナリオ 割合 必要 PV/秒 同時セッシ ョン シナリオ1 3,022 127 128 0.04 20% 600 14,761 シナリオ2 27 10 8 0.22 40% 1,200 5,550 シナリオ3 21 11 5 0.16 35% 1,050 6,720 シナリオ4 20 10 12 0.40 5% 150 375 3,000PV/sec
シナリオとその割合 シナリオ ユーザ 操作 処理 時間 仮想 PV 創出 PV/秒
シナリオ 割合 必要 PV/秒 同時セッシ ョン シナリオ1 3,022 127 128 0.04 20% 600 14,761 シナリオ2 27 10 8 0.22 40% 1,200 5,550 シナリオ3 21 11 5 0.16 35% 1,050 6,720 シナリオ4 20 10 12 0.40 5% 150 375 3,000PV/sec
シナリオとその割合 シナリオ ユーザ 操作 処理 時間 仮想 PV 創出 PV/秒
シナリオ 割合 必要 PV/秒 同時セッシ ョン シナリオ1 3,022 127 128 0.04 20% 600 14,761 シナリオ2 27 10 8 0.22 40% 1,200 5,550 シナリオ3 21 11 5 0.16 35% 1,050 6,720 シナリオ4 20 10 12 0.40 5% 150 375 3,000PV/sec
シナリオとその割合 シナリオ ユーザ 操作 処理 時間 仮想 PV 創出 PV/秒
シナリオ 割合 必要 PV/秒 同時セッシ ョン シナリオ1 3,022 127 128 0.04 20% 600 14,761 シナリオ2 27 10 8 0.22 40% 1,200 5,550 シナリオ3 21 11 5 0.16 35% 1,050 6,720 シナリオ4 20 10 12 0.40 5% 150 375
シナリオとその割合 シナリオ ユーザ 操作 処理 時間 仮想 PV 創出 PV/秒
シナリオ 割合 必要 PV/秒 同時セッシ ョン シナリオ1 3,022 127 128 0.04 20% 600 14,761 シナリオ2 27 10 8 0.22 40% 1,200 5,550 シナリオ3 21 11 5 0.16 35% 1,050 6,720 シナリオ4 20 10 12 0.40 5% 150 375
シナリオとその割合 シナリオ ユーザ 操作 処理 時間 仮想 PV 創出 PV/秒
シナリオ 割合 必要 PV/秒 同時セッシ ョン シナリオ1 3,022 127 128 0.04 20% 600 14,761 シナリオ2 27 10 8 0.22 40% 1,200 5,550 シナリオ3 21 11 5 0.16 35% 1,050 6,720 シナリオ4 20 10 12 0.40 5% 150 375
シナリオとその割合 シナリオ ユーザ 操作 処理 時間 仮想 PV 創出 PV/秒
シナリオ 割合 必要 PV/秒 同時セッシ ョン シナリオ1 3,022 127 128 0.04 20% 600 14,761 シナリオ2 27 10 8 0.22 40% 1,200 5,550 シナリオ3 21 11 5 0.16 35% 1,050 6,720 シナリオ4 20 10 12 0.40 5% 150 375
シナリオが出来た
• 耐えられる様にしたい • 負荷を想定 • 耐えられそうな仮構成を作る • 負荷を作り出して構成を調整 負荷 •
負荷がやってくる • どうやって耐えるか • Webサーバ(EC2)のスケールアウトで対応したい • DB(RDS)がツラければスケールアップする
システム構成 Ȑ Ȑ 2 × m4.large vCPU: 2 / memory:
8GB EC2 RDS db.m3.xlarge vCPU: 4 / memory: 7.5GB
システム構成 Ȑ Ȑ 2 × m4.large vCPU: 2 / memory:
8GB EC2 RDS db.m3.xlarge vCPU: 4 / memory: 7.5GB Ȑ Ȑ 16 × m4.large vCPU: 2 / memory: 8GB EC2 RDS db.m3.xlarge vCPU: 4 / memory: 7.5GB Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ
None
Apacheをちゃんと設定する • Apacheのプロセス数をいくつにする?
Apacheをちゃんと設定する • Apacheのプロセス数をいくつにする? $ ps aux USER PID %CPU %MEM
VSZ RSS TTY www-data 11270 0.0 0.3 441636 26720 ? STAT START TIME COMMAND S 06:25 0:02 /usr/sbin/apache2 -k start
Apacheをちゃんと設定する • Apacheのプロセス数をいくつにする? $ ps aux USER PID %CPU %MEM
VSZ RSS TTY www-data 11270 0.0 0.3 441636 26720 ? STAT START TIME COMMAND S 06:25 0:02 /usr/sbin/apache2 -k start
Apacheをちゃんと設定する • Apacheのプロセス数をいくつにする? $ ps aux USER PID %CPU %MEM
VSZ RSS TTY www-data 11270 0.0 0.3 441636 26720 ? STAT START TIME COMMAND S 06:25 0:02 /usr/sbin/apache2 -k start Ȑ m4.large vCPU: 2 / memory: 8GB
Apacheをちゃんと設定する • Apacheのプロセス数をいくつにする? $ ps aux USER PID %CPU %MEM
VSZ RSS TTY www-data 11270 0.0 0.3 441636 26720 ? STAT START TIME COMMAND S 06:25 0:02 /usr/sbin/apache2 -k start Ȑ m4.large vCPU: 2 / memory: 8GB 8GB中1.6GB(20%)くらいOSに…。 残り80%(6.4GB)をApacheに。
Apacheをちゃんと設定する • Apacheのプロセス数をいくつにする? $ ps aux USER PID %CPU %MEM
VSZ RSS TTY www-data 11270 0.0 0.3 441636 26720 ? STAT START TIME COMMAND S 06:25 0:02 /usr/sbin/apache2 -k start Ȑ m4.large vCPU: 2 / memory: 8GB 8GB中1.6GB(20%)くらいOSに…。 残り80%(6.4GB)をApacheに。 80% / 0.4% = 200
Apache設定 Timeout 10 KeepAliveTimeout 120 StartServers 200 MinSpareServers 200 MaxSpareServers
200 ServerLimit 200 MaxClients 200
• 耐えられる様にしたい • 負荷を想定 • 耐えられそうな仮構成を作る • 負荷を作り出して構成を調整 負荷 •
負荷がやってくる • どうやって耐えるか • Webサーバ(EC2)のスケールアウトで対応したい • DB(RDS)がツラければスケールアップする
負荷メーカーと言えば彼
None
JMeterでシナリオを実装する
JMeterでシナリオを実装する シナリオ ウェイト 処理 時間 仮想 PV 創出 PV/sec シナリオ
割合 必要 PV/秒 同時セッシ ョン シナリオ2 27 10 8 0.22 40% 1,200 5,550
JMeterでシナリオを実装する シナリオ ウェイト 処理 時間 仮想 PV 創出 PV/sec シナリオ
割合 必要 PV/秒 同時セッシ ョン シナリオ2 27 10 8 0.22 40% 1,200 5,550
シナリオが実装できた
よし負荷テストだ
None
実行!!
/ファー\ 実行!!
None
Macのファン全開
Macのファン全開 • 今回欲しかった並行実行数は27,000セッション。 • Mac 1台では負荷をかけきれない。
どうしたか
スケールアウト
システム構成 Ȑ Ȑ 16 × m4.large vCPU: 2 / memory:
8GB EC2 RDS db.m3.xlarge vCPU: 4 / memory: 7.5GB Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ
システム構成 Ȑ Ȑ 16 × m4.large vCPU: 2 / memory:
8GB EC2 RDS db.m3.xlarge vCPU: 4 / memory: 7.5GB Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ 5 × m4.large vCPU: 2 / memory: 8GB EC2 Ȑ Ȑ Ȑ
None
システム構成 Ȑ Ȑ 16 × m4.large vCPU: 2 / memory:
8GB EC2 RDS db.m3.xlarge vCPU: 4 / memory: 7.5GB Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ 5 × m4.large vCPU: 2 / memory: 8GB EC2 Ȑ Ȑ Ȑ
さて本格負荷テストだ
…
……
まったく捌けない
予想外にキツイ
予想外にキツイ • 負荷をかけ始めた瞬間にレスポンスが悪化し、 ELBから外される。 • すべてのWebサーバがELBから外されて ゲームオーバー。 • 5分と保たない。
どうしよう
対策を考えよう
まず起動プロセスを整理
APIコール Ȑ
APIコール Ȑ 端末登録
APIコール Ȑ 端末登録 デバイストークン登録
APIコール Ȑ 端末登録 デバイストークン登録 システム設定取得
APIコール Ȑ 端末登録 デバイストークン登録 システム設定取得 URLホワイトリスト取得
APIコール Ȑ 端末登録 デバイストークン登録 システム設定取得 URLホワイトリスト取得 お知らせ取得
負荷対策 • APIの特徴: 多くは参照系かつ全員同じ。
負荷対策 • APIの特徴: 多くは参照系かつ全員同じ。 →静的ファイル化してしまおう • CakePHPを使っている • app/webroot 配下にファイルを置けばApacheだけでリクエ
スト & レスポンスが完了する。 • CakePHPが実行されないので(PHP比)超高速に処理可能。
どうなったか
爆★速
Ȑ システム設定取得
Ȑ システム設定取得
静的ファイル化 • いくつかのAPIを静的ファイル化 → 現実的な速度が出る様になった。 • 副作用: 管理画面から値を変更してもAPIに反映されない • この高負荷体制は数日間の時限なのであまり問題にならな
い。
負荷テスト完了
• Webサーバ、16 x m4.xlarge で大丈夫そう。 • 結局、4 x m4.4xlarge にした。
• Apacheのプロセス数は2,116。 • 大丈夫 = Apacheがエラーを吐かない • エラーを吐くとELBからはずされてサービスダウン 負荷テストの結果
• Webサーバ、16 x m4.xlarge で大丈夫そう。 • 結局、4 x m4.4xlarge にした。
• Apacheのプロセス数は2,116。 • 大丈夫 = Apacheがエラーを吐かない • エラーを吐くとELBからはずされてサービスダウン 負荷テストの結果
• Webサーバ、16 x m4.xlarge で大丈夫そう。 • 結局、4 x m4.4xlarge にした。
• Apacheのプロセス数は2,116。 • 大丈夫 = Apacheがエラーを吐かない • エラーを吐くとELBからはずされてサービスダウン 負荷テストの結果
• Webサーバ、16 x m4.xlarge で大丈夫そう。 • 結局、4 x m4.4xlarge にした。
• Apacheのプロセス数は2,116。 • 大丈夫 = Apacheがエラーを吐かない • エラーを吐くとELBからはずされてサービスダウン 負荷テストの結果
• Webサーバ、16 x m4.xlarge で大丈夫そう。 • 結局、4 x m4.4xlarge にした。
• Apacheのプロセス数は2,116。 • 大丈夫 = Apacheがエラーを吐かない • エラーを吐くとELBからはずされてサービスダウン 負荷テストの結果 お得
• Webサーバ、16 x m4.xlarge で大丈夫そう。 • 結局、4 x m4.4xlarge にした。
• Apacheのプロセス数は2,116。 • 大丈夫 = Apacheがエラーを吐かない • エラーを吐くとELBからはずされてサービスダウン 負荷テストの結果
よし、これで万全!
そんなふうに考えていた時期が 俺にもありました
さて当日
タイムスケジュール 2/28 10:00 サイトクローズ・アプリクローズ 16:00 PUSH通知 3/01 00:00 サイトオープン・アプリオープン 01:00
PUSH通知 11:00 アプリアップデート強制ON 2/27 12:00 PUSH通知
タイムスケジュール 2/28 10:00 サイトクローズ・アプリクローズ 16:00 PUSH通知 3/01 00:00 サイトオープン・アプリオープン 01:00
PUSH通知 11:00 アプリアップデート強制ON 2/27 12:00 PUSH通知
アプリアップデート強制ON PUSH通知
アプリアップデート強制ON PUSH通知 天井張り付き
むむっ!?
タイムスケジュール 2/28 10:00 サイトクローズ・アプリクローズ 16:00 PUSH通知 3/01 00:00 サイトオープン・アプリオープン 01:00
PUSH通知 11:00 アプリアップデート強制ON 2/27 18:00 API静的化 12:00 PUSH通知
アプリアップデート強制ON PUSH通知
アプリアップデート強制ON PUSH通知
アプリアップデート強制ON PUSH通知 API静的化
ひと安心
タイムスケジュール 2/28 10:00 サイトクローズ・アプリクローズ 16:00 PUSH通知 3/01 00:00 サイトオープン・アプリオープン 01:00
PUSH通知 11:00 アプリアップデート強制ON 2/27 18:00 API静的化 12:00 PUSH通知
アプリクローズ Ȑ 端末登録 デバイストークン登録 システム設定取得
アプリクローズ Ȑ 端末登録 デバイストークン登録 システム設定取得 「アプリクローズ」
タイムスケジュール 2/28 10:00 サイトクローズ・アプリクローズ 16:00 PUSH通知 3/01 00:00 サイトオープン・アプリオープン 01:00
PUSH通知 11:00 アプリアップデート強制ON 2/27 18:00 API静的化 12:00 PUSH通知
None
None
まあまあ…落ち着いた
タイムスケジュール 2/28 10:00 サイトクローズ・アプリクローズ 16:00 PUSH通知 3/01 00:00 サイトオープン・アプリオープン 01:00
PUSH通知 11:00 アプリアップデート強制ON 2/27 18:00 API静的化 12:00 PUSH通知
2/28 9:00 JST 15:00 JST 21:00 JST 9:00 JST 3/1
3:00 JST サイト・アプリオープン RDS
2/28 9:00 JST 15:00 JST 21:00 JST 9:00 JST 3/1
3:00 JST サイト・アプリオープン 0:03JST 1,800リクエスト/秒 RDS
2/28 9:00 JST 15:00 JST 21:00 JST 9:00 JST 3/1
3:00 JST サイト・アプリオープン 0:03JST 1,800リクエスト/秒 RDS
昼になっても落ち着かない…
対策するか…
APIコール Ȑ 端末登録 デバイストークン登録 システム設定取得 URLホワイトリスト取得 お知らせ取得
APIコール Ȑ 端末登録 デバイストークン登録 システム設定取得 URLホワイトリスト取得 お知らせ取得 静的 静的 静的
APIコール Ȑ 端末登録 デバイストークン登録 システム設定取得 URLホワイトリスト取得 お知らせ取得 静的 静的 静的
動的 動的
APIコール Ȑ 端末登録 デバイストークン登録 システム設定取得 URLホワイトリスト取得 お知らせ取得 静的 静的 静的
動的 動的 初回のみ
APIコール Ȑ 端末登録 デバイストークン登録 システム設定取得 URLホワイトリスト取得 お知らせ取得 静的 静的 静的
動的 動的 初回のみ 起動のたび
None
デバイストークン登録API、 ユーザを探すSQLが遅いな…
デバイストークン登録API、 ユーザを探すSQLが遅いな… 検索キーにインデックスが無い…
デバイストークン登録API、 ユーザを探すSQLが遅いな… 検索キーにインデックスが無い… 開発環境で…
mysql> explain select * from users where *****************************; +----+-------------+-------+------------+------+---------------+------+---------+- |
id | select_type | table | partitions | type | possible_keys | key | key_len | +----+-------------+-------+------------+------+---------------+------+---------+- | 1 | SIMPLE | users | NULL | ALL | NULL | NULL | NULL | +----+-------------+-------+------------+------+---------------+------+---------+- 1 row in set, 1 warning (0.00 sec) mysql> select id from users where *****************************; +----+ | id | +----+ | 1 | +----+ 1 row in set (0.25 sec)
mysql> explain select * from users where *****************************; +----+-------------+-------+------------+------+---------------+------+---------+- |
id | select_type | table | partitions | type | possible_keys | key | key_len | +----+-------------+-------+------------+------+---------------+------+---------+- | 1 | SIMPLE | users | NULL | ALL | NULL | NULL | NULL | +----+-------------+-------+------------+------+---------------+------+---------+- 1 row in set, 1 warning (0.00 sec) mysql> select id from users where *****************************; +----+ | id | +----+ | 1 | +----+ 1 row in set (0.25 sec) フルスキャンになってて0.25secかかってる…。 インデックス足してみよう。
mysql> explain select * from users where *****************************; +----+-------------+-------+------------+------+---------------+------------+---------+- |
id | select_type | table | partitions | type | possible_keys | key | key_len | +----+-------------+-------+------------+------+---------------+------------+---------+- | 1 | SIMPLE | users | NULL | ref | index_hash | index_hash | 162 | +----+-------------+-------+------------+------+---------------+------------+---------+- 1 row in set, 1 warning (0.00 sec) mysql> select id from users where *****************************; +----+ | id | +----+ | 1 | +----+ 1 row in set (0.00 sec)
mysql> explain select * from users where *****************************; +----+-------------+-------+------------+------+---------------+------------+---------+- |
id | select_type | table | partitions | type | possible_keys | key | key_len | +----+-------------+-------+------------+------+---------------+------------+---------+- | 1 | SIMPLE | users | NULL | ref | index_hash | index_hash | 162 | +----+-------------+-------+------------+------+---------------+------------+---------+- 1 row in set, 1 warning (0.00 sec) mysql> select id from users where *****************************; +----+ | id | +----+ | 1 | +----+ 1 row in set (0.00 sec) 効果絶大やんけ…。
None
本番に足したろ。
本番に足したろ。 mysql> alter table users add index …
本番に足したろ。 mysql> alter table users add index … 返ってこない…。 しかし
Ctrl + C も怖い。 しばらく置いておこう…。
本番に足したろ。 mysql> alter table users add index … 返ってこない…。 しかし
Ctrl + C も怖い。 しばらく置いておこう…。
本番に足したろ。 mysql> alter table users add index … 返ってこない…。 しかし
Ctrl + C も怖い。 しばらく置いておこう…。 DBサーバの負荷がむっちゃ 下がったんですが、 何か起きてますか!?
RDS
インデックス追加完了 RDS
むっちゃサックサクに
めでたい!
まとめ
まとめ • 1,800リクエスト/秒の世界を体験した。 • 負荷試験 & 対策 • 負荷をかけるのにも工夫が必要。 •
Apacheのエラーレートだけでなくサーバの リソース利用状況もチェックするべき。 • チューニング • Apacheで完結するアクセスは爆速。 • レコード数が多いテーブルではインデックス特に大事。
あたりまえのことを あたりまえに
Thanks WE ARE HIRING @tomzoh プリーズ: #phpconfuk / ブログ /
懇親会
AWS / EC2の注意点 • いろいろなものに制限がある。 • EC2インスタンス数 • IPアドレス数 •
どちらも申請すると上げてもらえるけど1〜2営業日必要 • 負荷テストをする時にも申請が必要 • これも1〜2営業日
告知
builderscon tokyo 2017 2017.08.3(木)〜5(土) https://builderscon.io/tokyo/2017 チケット販売中
iOSDC Japan 2017 https://iosdc.jp/2017/ スポンサー募集中 2017.09.15(金)〜17(日)
PHPerKaigi 2018 https://phperkaigi.jp スポンサー募集…するかも 2018.03.10(土) • PHPerのためのカンファレンス • 東京都練馬区 Coconeriホールにて
• 朝から晩までテックトーク • 夕方からはビールを飲みながら • 夜はクラフトビールで懇親会
Thanks WE ARE HIRING @tomzoh プリーズ: #phpconfuk / ブログ /
懇親会