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.5k
秒間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
asumikamというカンファレンスオーガナイザの凄さを語る / The Brilliance of Asumikam
tomzoh
1
300
なぜキャッシュメモリは速いのか 余談集 / Why is Cache Memory So Fast? Extended.
tomzoh
0
130
なぜキャッシュメモリは速いのか / Why is Cache Memory So Fast?
tomzoh
2
1.2k
PHPからはじめるコンピュータアーキテクチャ 15分ダイジェスト版 / PHP Meets Silicon: A Fun Dive into Computer Structures 15mins ver
tomzoh
2
240
PHPでXOAUTH2を使ってGmailからメールを取り込む / Getting Mail from Gmail with XOAUTH2 in PHP
tomzoh
0
470
PHPからはじめるコンピュータア ーキテクチャ / PHP Meets Silicon: A Fun Dive into Computer Structures PHP Conference 2023 ver
tomzoh
0
370
PHPからはじめるコンピュータア ーキテクチャ / PHP Meets Silicon: A Fun Dive into Computer Structures
tomzoh
4
620
NANDがあればNANDeもできる / With NAND, you can do anything
tomzoh
0
490
コンピュータはなぜ0と1なのか / How and Why Computers Operate Using Binary Code
tomzoh
0
430
Other Decks in Programming
See All in Programming
テストケースの名前はどうつけるべきか?
orgachem
PRO
0
130
たのしいparse.y
ydah
3
120
複雑な仕様に立ち向かうアーキテクチャ
myohei
0
170
短期間での新規プロダクト開発における「コスパの良い」Goのテスト戦略」 / kamakura.go
n3xem
2
170
LLM Supervised Fine-tuningの理論と実践
datanalyticslabo
3
960
Итераторы в Go 1.23: зачем они нужны, как использовать, и насколько они быстрые?
lamodatech
0
650
アクターシステムに頼らずEvent Sourcingする方法について
j5ik2o
4
180
The rollercoaster of releasing an Android, iOS, and macOS app with Kotlin Multiplatform | droidcon Italy
prof18
0
150
useSyncExternalStoreを使いまくる
ssssota
6
1k
Fibonacci Function Gallery - Part 1
philipschwarz
PRO
0
200
Zoneless Testing
rainerhahnekamp
0
120
fs2-io を試してたらバグを見つけて直した話
chencmd
0
220
Featured
See All Featured
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
1.9k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
KATA
mclloyd
29
14k
How To Stay Up To Date on Web Technology
chriscoyier
789
250k
GraphQLの誤解/rethinking-graphql
sonatard
67
10k
Documentation Writing (for coders)
carmenintech
66
4.5k
We Have a Design System, Now What?
morganepeng
51
7.3k
4 Signs Your Business is Dying
shpigford
181
21k
Product Roadmaps are Hard
iamctodd
PRO
49
11k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
665
120k
Rails Girls Zürich Keynote
gr2m
94
13k
Side Projects
sachag
452
42k
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 / ブログ /
懇親会