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
Laravelで学ぶ Webアプリケーションチューニングの基本 / Web Applicati...
Search
Ryo Tomidokoro
February 16, 2019
Technology
10
5.5k
Laravelで学ぶ Webアプリケーションチューニングの基本 / Web Application Tuning Guildline
Laravel Jp Conferenceの資料です。
どのようにウェブアプリケーションのパフォーマンスチューニングを考えていくのか、基本をまとめました。
Ryo Tomidokoro
February 16, 2019
Tweet
Share
More Decks by Ryo Tomidokoro
See All by Ryo Tomidokoro
集中して作業する技術/how_to_work_deeply
hanhan1978
58
38k
PHPでデータベースを作ってみた/create-data-with-php
hanhan1978
10
8.7k
ADRを一年運用してみた/adr_after_a_year
hanhan1978
8
3.2k
B+木入門:PHPで理解する データベースインデックスの仕組み/b-plus-tree-101
hanhan1978
5
4.2k
ADRを一年運用してみた/our_story_about_adr
hanhan1978
5
1.8k
PHPで学ぶ Session の基本と応用 / web-app-session-101-2024
hanhan1978
12
5.3k
レガシー回避のPHP開発術/avoid_php_legacy
hanhan1978
16
12k
Laravel Collectionの計算量を調べてみた2023/laravel_collection_time_complexity_2023
hanhan1978
1
1.3k
PHP で学ぶ Cache の距離の話 / study_cache_with_php
hanhan1978
7
2k
Other Decks in Technology
See All in Technology
なぜクラウドサービスで Web コンソールを提供するのか
shuta13
4
1.9k
デジタル化・DX推進あるある
y150saya
0
230
Datadog を使ったプロダクトとクラウドの セキュリティモニタリング
mrtc0
0
580
Practical GenAI with Go - Elastic and Golang Sydney
adriancole
0
140
強いチームを夢見て-PMからSREに転身して1年の振り返り / 20240906_bengo4_sre
bengo4com
2
810
Zero Data Loss Autonomous Recovery Service サービス概要
oracle4engineer
PRO
0
3.2k
Estrategias de escalabilidade para projetos web
jessilyneh
2
200
突撃! 隣のAmazon Bedrockユーザー 〜YouはどうしてAWSで?〜
minorun365
PRO
2
200
SAVEPOINT α版
savepoint
0
410
CRTO/CRTL/OSEPの比較・勉強法とAV/EDRの検知実験
chayakonanaika
1
950
データウェアハウス製品のSnowflakeでPythonが動くって知ってました?
foursue
1
160
セキュリティ監視の内製化 効率とリスク
mixi_engineers
PRO
7
820
Featured
See All Featured
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
225
22k
Designing on Purpose - Digital PM Summit 2013
jponch
113
6.8k
Designing the Hi-DPI Web
ddemaree
278
34k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
29
2.6k
How to Ace a Technical Interview
jacobian
275
23k
How to Think Like a Performance Engineer
csswizardry
16
920
Practical Orchestrator
shlominoach
185
10k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Optimizing for Happiness
mojombo
375
69k
Rebuilding a faster, lazier Slack
samanthasiow
78
8.5k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
28
2.2k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Transcript
Laravelで学ぶ Webアプリケーションチューニングの基本 Laravel Jp Conference 2019/02/16
自己紹介 名前 : 富所 亮 | Ryo Tomidokoro 職業 :
Web Application Engineer 職歴 : SIer > 事業会社 > 受託 > 受託 所属 : Innovator Japan Inc. 主な出現場所 : PHP界隈の各種勉強会
諸注意 スライドはSpeakerDeckにアップ済みです。 写真はご自由に。でも周りに気をつけて…
はじめに
本トークの内容 自分がいつもやっていることをまとめました 現場や個人開発でやったこと、本で読んで学んだこ とがベースになっています
いきなりですが質問です
パフォーマンスチューニング したことありますか?
経験者の方へ ご自身のやり方と比べて見てください 改善のヒントになったら幸いです
未経験者の方へ チューニングは職人芸ではない やることが分かれば怖くない
本トークの目指すところ 特にチューニングの経験が浅い方にとって まず何をどうしてよいか分からない!?という状態 を解消することに重点を置いています。
基本的なことを再確認することで パフォーマンスチューニングでやるべきことが明確 になることを期待しています。
ついでに Laravelが持つ基本的な機能がどのようなケースで 役立つのかを紹介します 必要十分な機能がすでに備わっています
アウトライン 1. 全体を見る 2. パフォーマンスを科学する 3. ウェブアプリの責任? 4. サーバーメトリクスを確認する 5.
ウェブアプリの処理を特定する 6. プロファイリングする 7. 改善ループを回す 8. よくある問題処理とその対処
1. 全体を見る 2. パフォーマンスを科学する 3. ウェブアプリの責任? 4. サーバーメトリクスを確認する 5. ウェブアプリの処理を特定する
6. プロファイリングする 7. 改善ループを回す 8. よくある問題処理とその対処
1. 全体を見る
遅いとは? とても曖昧な言葉。 私の「遅い」と あなたの「遅い」は比較出来ない 「遅い」は主観、個人差がある。
曖昧な意見 「うちのウェブアプリケーション遅くない?」
問題を提起しているように見えて何もかもが曖昧で 分からない このような「遅い」では改善が行えない。
具体的な意見 「弊社のウェブアプリは 平日18:00〜19:00の時間帯で 通常よりも500msec応答速度が遅い」
コンテキストや数値が説明されることで、具体的な 状況が浮彫になってくる こういう「遅い」は改善につながる
まず、曖昧な「遅い」を数値で表せる「遅い」に変換 する必要があります。 「推測するな計測せよ」の世界です。
状況が分かったとして、何が原因で「遅い」発生して いるかは分かりません。 原因究明のために、ウェブアプリに関わる全体をみ る必要があります。
ウェブアプリケーションは どのようにしてブラウザに表示されるのか?
ウェブアプリケーションの全体像 ネットワークはなぜつながるのか? - 戸根勤(日経BP社) P10
自分の領域の狭さを知る Laravel
アンコントローラブルな領域 ウェブアプリだけでは改善できない領域が沢山ある そもそもウェブアプリが「遅い」の原因なのかも分か らない
遅いの原因をつきとめる なんとなくアタリをつけてはいけない エンジニアとして科学的に突き止める必要があるが ‥どうする?
1. 全体を見る 2. パフォーマンスを科学する 3. ウェブアプリの責任? 4. サーバーメトリクスを確認する 5. ウェブアプリの処理を特定する
6. プロファイリングする 7. 改善ループを回す 8. よくある問題処理とその対処
2. パフォーマンスを科学する
「遅い」の考え方
レイテンシー 任意の状態から、任意の状態まで 待つためにかかった時間を計測した値 例) HTTPのリクエストからレスポンスまで DBのクエリ送信からデータ受信まで 詳解システム・パフォーマンス Brendan Gregg 西脇靖紘
長尾高弘(オライリー・ジャパン)
ウェブアプリ全体のレイテンシー ユーザー側 ネットワーク プロバ イダ プロバ イダ 光ファイバー等 サーバー側 ネットワーク
レイテンシーの中身をみて、ウェブアプリ単体のレス ポンスタイムがボトルネックで無い場合 ウェブアプリ以外で対処する方が効率が良い
例えば大陸間のネットワーク通信 速度制限のかかった格安SIM 共有LAN内の輻輳 ウェブアプリ以外の遅さ
EC2で試してみる
Tokyo vs USA Tokyo Region Ubuntu 16.06 LTS N. Virginia
Region Ubuntu 16.06 LTS
東京のブラウザからアクセス Tokyo N. Virginia
大陸間の移動でかかる時間 アメリカ大陸まで +200msec ウェブアプリケーションでは改善できない! CDN等のソリューションが必要
1. 全体を見る 2. パフォーマンスを科学する 3. ウェブアプリの責任? 4. サーバーメトリクスを確認する 5. ウェブアプリの処理を特定する
6. プロファイリングする 7. 改善ループを回す 8. よくある問題処理とその対処
3. ウェブアプリの責任?
全体のレイテンシーの中でサーバー側ネットワーク の占める割合が大きい場合 ウェブアプリをチューニングすることで得られる可能 性が高い ユーザー側 ネットワーク プロバ イダ プロバ イダ
光ファイ バー等 サーバー側 ネットワーク
レイテンシーにおけるウェブアプリ単体の占める時 間は、ウェブサーバーが記録する「レスポンスタイ ム」で知ることが出来る
レスポンスタイム 各ウェブサーバーはログにレスポンスタイムを出力 することが出来る。 Apache : %D Nginx : $request_time H2O
: duration
ウェブアプリ単体のレイテンシー サーバー側ネットワーク ウェブサーバーのレスポンスタイム その他通信
ウェブアプリ全体のレイテンシーを確認して、ウェブ アプリ単体の応答時間に原因があると分かって、は じめて ウェブアプリのチューニングを開始できる。
しかし、ウェブアプリ単体のレスポンスが悪かったと して、本当にウェブアプリが悪いのでしょうか? その「遅さ」はウェブアプリの責任?
1. 全体を見る 2. パフォーマンスを科学する 3. ウェブアプリの責任? 4. サーバーメトリクスを確認する 5. ウェブアプリの処理を特定する
6. プロファイリングする 7. 改善ループを回す 8. よくある問題処理とその対処
4. サーバーメトリクスを見る
ウェブアプリ以外の原因 同一サーバー上で動く他のプロセスがリソースを消 費しているケースがある 例)誰かが閉じ忘れたemacsのプロセスが100%で張 り付いてた…とか
原因を探るための指標 メモリ使用量、CPU使用率、ディスクIO、ネットワーク IO etc… 継続的な測定が基本。中長期の傾向値が無いと判 断がしづらい
測定ツール sysstatパッケージ ホスティングが提供するツール (CloudWatch) SaaSの監視ツール (Mackerel) インストール型の測定ツール (netdata)
sysstatパッケージ sar, pidstat, dstat ...
Mackerel
netdata
ボトルネックを特定する この段階では、プロセス単位でのCPU使用率、メモ リ使用量などから、どのプロセスがボトルネックに なっているのかを特定 一個ずつ一個ずつ、原因を絞り込んでいく
ついにウェブアプリが原因らしいということが分かっ た じゃあ、次は何をしたらいい?
1. 全体を見る 2. パフォーマンスを科学する 3. ウェブアプリの責任? 4. サーバーメトリクスを確認する 5. ウェブアプリの処理を特定する
6. プロファイリングする 7. 改善ループを回す 8. よくある問題処理とその対処
5. ウェブアプリの処理を特定する
ウェブアプリのどの処理が原因なのか? どうやったら分かるのか? この段階では 「PHPのプログラムが原因らしい」 としか分かっていない。
レスポンスタイムから探す ウェブサーバーのログから、レスポンスタイムが遅 いURLを探す awk, alp, kataribe等を使って簡単に解析できる
alpの例
ウェブ系ツールを頼る 自分はNew Relicしか使ったことないのですが、簡単 にボトルネックのURLや処理を特定することができ ます。
New Relicの例
1. 全体を見る 2. パフォーマンスを科学する 3. ウェブアプリの責任? 4. サーバーメトリクスを確認する 5. ウェブアプリの処理を特定する
6. プロファイリングする 7. 改善ループを回す 8. よくある問題処理とその対処
6. プロファイリングする
プロファイリング? コード実行時にどの処理にどのくらいの時間がか かっているのかを計測したもの と、言葉で言われてもピンとこないので実例を見た ほうが早い
blackfire.ioの例
その他のツール Xdebug Xhprof tideways 他にもありそうです…
処理が特定できて、プロファイラーの結果が取得で きたら、チューニングの準備がようやく整ったことに なる ここから、ウェブアプリ単体のレイテンシーについて 考えていく段階になる
1. 全体を見る 2. パフォーマンスを科学する 3. ウェブアプリの責任? 4. サーバーメトリクスを確認する 5. ウェブアプリの処理を特定する
6. プロファイリングする 7. 改善ループを回す 8. よくある問題処理とその対処
7. 改善ループを回す
ウェブアプリ単体のレイテンシー レスポンス出力 APIコール Routing DBクエリー Library読込 例)
この先は、レイテンシーの中でボトルネックになって いる処理をチューニングしていく この先は 1. レイテンシー確認 2. ボトルネック改善 3. レイテンシー確認... を延々と繰り返す
改善ループ1
改善ループ1
理論上400msec程度のパフォーマンス改善が見込 める →仮に上手に改善できたとすると…
改善ループ2
改善ループ2
ボトルネックが他の処理に移ったことがわかる ここも改善することでさらに200msec →上手く改善すると...
改善ループ3
処理の特定さえ出来てしまえば、あとはTry&Errorを 繰り返すことでチューニングは達成することが出来 る。 処理の特定はプロファイラがやってくれる
1. 全体を見る 2. パフォーマンスを科学する 3. ウェブアプリの責任? 4. サーバーメトリクスを確認する 5. ウェブアプリの処理を特定する
6. プロファイリングする 7. 改善ループを回す 8. よくある問題処理とその対処
8. よくある問題とその対処
この先は、個別の象徴的なケースを例にとって、そ の対処法を説明します。 →Laravelにちょうどよい解決法があるものは[L] マークがついています!
HTTPのAPIコール 一回のリクエストで複数APIをコールするようになる と、途端に処理が遅くなる →更新頻度によってはCache [L] →自前APIであれば、専用APIにまとめてコール回 数を減らす →フロントのJSに移譲する
メール送信 SMTPとの通信は体感1secくらいかかる。複数メー ル送信がリクエストに同期的に書いてあると絶望的 に遅い →Queue [L]
Slack通知 これもメール送信と同じ。同期的な処理にしていると びっくりするほど遅くなります。 →Queue [L]
SQLクエリー実行 @soudai1025 のスライド見れば多分解決… 単発のクエリーが遅い場合は適切なDB設計と、イ ンデックス設計が効きます。 →SELECTであればCacheという手もあります。あま りオススメしませんが…[L]
リスト形式の表示で問題になるやつです。Laravelの relationをbladeから呼び出すと、カジュアルに大量 のクエリを発生させられます。 →eager loading [L] N+1クエリ
入れ子のLoopとか、1万件とかのforeachとか、常識 を外れた蛮行によるもの… Laravel Collectionの乱用なども… →レビューや内部勉強会で防ぐしかない… 計算量が無駄に多いプログラム
こちらにも詳しく書きました https://speakerdeck.com/hanhan1978/laravel-collectionfalseji-suan-liang-wodiao-betemita
色々、見てきましたが処理の遅いプログラムの チューニング方法は対処方法が2つくらいしか無 い。 ・アルゴリズムの変更 ・非同期化
チューニングとは、全体を見ながら少しずつ少しず つ原因を特定していくプロセスです。 泥臭く追い込んでいく一連の作業をやってみると、 ウェブアプリの理解がさらに深まります。 最後に…
参考資料 詳解システム・パフォーマンス Brendan Gregg 西脇靖紘 長尾高弘 オライリー・ジャパン ネットワークはなぜつながるのか? 戸根勤 日経BP社
サーバー・インフラを支える技術 伊藤 直也, 勝見 祐己, 田中 慎司, ひろせ まさあき, 安井 真伸, 横川 和哉 WEB+DB PRESS plus