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.6k
秒間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
350
なぜキャッシュメモリは速いのか 余談集 / Why is Cache Memory So Fast? Extended.
tomzoh
0
150
なぜキャッシュメモリは速いのか / Why is Cache Memory So Fast?
tomzoh
3
1.3k
PHPからはじめるコンピュータアーキテクチャ 15分ダイジェスト版 / PHP Meets Silicon: A Fun Dive into Computer Structures 15mins ver
tomzoh
2
250
PHPでXOAUTH2を使ってGmailからメールを取り込む / Getting Mail from Gmail with XOAUTH2 in PHP
tomzoh
0
490
PHPからはじめるコンピュータア ーキテクチャ / PHP Meets Silicon: A Fun Dive into Computer Structures PHP Conference 2023 ver
tomzoh
0
390
PHPからはじめるコンピュータア ーキテクチャ / PHP Meets Silicon: A Fun Dive into Computer Structures
tomzoh
4
620
NANDがあればNANDeもできる / With NAND, you can do anything
tomzoh
0
540
コンピュータはなぜ0と1なのか / How and Why Computers Operate Using Binary Code
tomzoh
0
450
Other Decks in Programming
See All in Programming
法律の脱レガシーに学ぶフロントエンド刷新
oguemon
3
190
DevFest - Serverless 101 with Google Cloud Functions
tunmise
0
140
JavaScriptツール群「UnJS」を5分で一気に駆け巡る!
k1tikurisu
5
140
ASP. NET CoreにおけるWebAPIの最新情報
tomokusaba
0
190
rails newと同時に型を書く
aki19035vc
6
740
個人アプリを2年ぶりにアプデしたから褒めて / I just updated my personal app, praise me!
lovee
0
300
Amazon Bedrock Multi Agentsを試してきた
tm2
1
190
月刊 競技プログラミングをお仕事に役立てるには
terryu16
1
1.2k
チームの立て直し施策をGoogleの 『効果的なチーム』と見比べてみた
maroon8021
0
200
2,500万ユーザーを支えるSREチームの6年間のスクラムのカイゼン
honmarkhunt
6
3.8k
2024年のkintone API振り返りと2025年 / kintone API look back in 2024
tasshi
0
160
いりゃあせ、PHPカンファレンス名古屋2025 / Welcome to PHP Conference Nagoya 2025
ttskch
1
240
Featured
See All Featured
Embracing the Ebb and Flow
colly
84
4.5k
Raft: Consensus for Rubyists
vanstee
137
6.7k
VelocityConf: Rendering Performance Case Studies
addyosmani
327
24k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
3
370
Visualization
eitanlees
146
15k
The Cult of Friendly URLs
andyhume
78
6.2k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
29
980
Fantastic passwords and where to find them - at NoRuKo
philnash
50
3k
StorybookのUI Testing Handbookを読んだ
zakiyama
28
5.4k
Keith and Marios Guide to Fast Websites
keithpitt
410
22k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Docker and Python
trallard
43
3.2k
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 / ブログ /
懇親会