Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
PHP で学ぶ Cache の距離の話 / study_cache_with_php
Search
Ryo Tomidokoro
March 23, 2023
Technology
2.8k
7
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
PHP で学ぶ Cache の距離の話 / study_cache_with_php
PHPerKaigi 2023 登壇資料
Ryo Tomidokoro
March 23, 2023
More Decks by Ryo Tomidokoro
See All by Ryo Tomidokoro
Laravelで学ぶ Webアプリケーションチューニング入門/web_application_tuning_101
hanhan1978
4
2.3k
あるアーキテクチャ決定と その結果/architecture-decision-and-its-result
hanhan1978
2
1.8k
開発者が知っておきたい複雑さの正体/where-the-complexity-comes-from
hanhan1978
8
3.8k
Spec Driven Development入門/spec_driven_development_for_learners
hanhan1978
2
1.9k
フロントエンドがTypeScriptなら、バックエンドはPHPでもいいじゃない/php-is-not-bad
hanhan1978
8
14k
どうすると生き残れないのか/how-not-to-survive
hanhan1978
17
15k
100分で本番デプロイ!Laravelで作るWebアプリケーション作成/100min_web_app_cicd
hanhan1978
1
300
PHPerのための計算量入門/Complexity101 for PHPer
hanhan1978
8
3.9k
集中して作業する技術/how_to_work_deeply
hanhan1978
69
61k
Other Decks in Technology
See All in Technology
[2026-09-11]SREは誰のもの?運用エンジニアが始める 「SRE領域への越境」とチームの進化の軌跡 〜Road to NEXT CRE
tosite
0
200
目の前の楽しいが人生を変える - コミュニティの螺旋の歩き方と楽しむコツ / change your life
soudai
PRO
4
550
安心して変更できるWebフロントエンドの作り方
pirosikick
4
2.1k
AIで仕事のやり方を変える
matsu7874
3
1.1k
10Xに技術的負債をもたらした「2つの境界の歪み」その構造と解消への営み
10xinc
0
1.3k
空間オーディオで過去の 自分(ゴースト)と競うランニング 〜HealthKitのルートを足音に変える実装〜
nao_randd
0
130
2026-09-10 【Snowflake World Tour Tokyo 2026】dbt Core と Snowflake で実現する多層的なデータガバナンス / Multi-Layered Data Governance Powered by dbt Core and Snowflake
civitaspo
0
380
ユーザー価値を届け続けるためにウォンテッドリーが大切にしている文化
kotaminato
0
140
山手線を徒歩で一周してわかった、 位置情報アプリは「足」が最強のデバッガー
hinakko
0
140
AIネイティブプロダクトで顧客価値を最大化するプロダクトエンジニアとFDEの協働
righttouch
PRO
0
280
Claude Code本って、 読む必要あるの?
oikon48
2
440
現場で役立つ技術負債の効果的な返済方法
masuda220
PRO
1
1k
Featured
See All Featured
Done Done
chrislema
186
16k
Are puppies a ranking factor?
jonoalderson
2
3.9k
AI Search: Where Are We & What Can We Do About It?
aleyda
0
7.9k
Primal Persuasion: How to Engage the Brain for Learning That Lasts
tmiket
0
450
Faster Mobile Websites
deanohume
310
32k
Building a Scalable Design System with Sketch
lauravandoore
464
34k
Building a Modern Day E-commerce SEO Strategy
aleyda
45
9.2k
Lightning talk: Run Django tests with GitHub Actions
sabderemane
0
250
Believing is Seeing
oripsolob
1
220
Documentation Writing (for coders)
carmenintech
77
5.5k
Code Review Best Practice
trishagee
74
20k
Rebuilding a faster, lazier Slack
samanthasiow
85
9.6k
Transcript
@hanhan1978 PHPで学ぶ Cacheの距離 の話 PHPerKaigi 2023
@hanhan1978 • 富所 亮 • 所属 株式会社カオナビ BackEnd Re-architecturing Team
(BERT) • 職業 バックエンドエンジニア • ブログ https://blog.hanhans.net • Yokohama North AM https://anchor.fm/yokohama-north-am 2
まずはこれを見てほしい 3
4 レイテンシーの表 https://colin-scott.github.io/personal_website/research/interactive_latency.html
5 本トークの目標
6 Cache をテーマに 新しい視点 を獲得してほしい
7 そもそも Cache とは?
8 https://www.weblio.jp/content/cache weblio - デジタル大辞泉
ようするに...... デジタルデータストア 9
10 Cache する とは?
プログラミングの文脈で Cacheする と表現した場合 デジタルデータストア を使ったバッファリング 11
12 バッファリング とは?
13 https://www.weblio.jp/content/バッファリング weblio - デジタル大辞泉
14 バッファリング 日常的にも使われている
例 : 宅配便 1. 荷受け場所 → 地域の中継施設 → 県の中継施設 <<
大型輸送手段で一気に運ぶ >> 2. 県の中継施設 → 地域の中継施設 → 最寄の宅配便 15
16 宅配便におけるバッファリング バッファリング
17 プログラミングにおける例
18 プログラマーのためのCPU入門 : 第五章 キャッシュメモリ より CPU - 命令キャッシュ -
データキャッシュ 命令流の高密度化が損なわれる ことを緩和
19 Linux の仕組み : 第8章 記憶階層 より OS のページキャッシュ 低速ストレージのアクセス速度向
上のため、ファイルデータをメモリ にキャッシュ
20 https://speakerdeck.com/hanhan1978/preload-and-jit PHP の OPCache コンパイルされた内容をメモリに キャッシュ
21 https://speakerdeck.com/hanhan1978/preload-and-jit CDN を使ったウェブコンテンツ配信 Akamai, CloudFront, CloudFlare エッジでの WASM とかも
距離を減らす戦略の一つ
22 いろいろな例をみた上で キャッシュを使うパターンを考える
キャッシュのパターン - より近いデータストアにデータを置く - 演算結果をデータストアに置く 23
キャッシュのパターン - より近いデータストアにデータを置く - 演算結果をデータストアに置く 24 IOバッファ 演算バッファ
IOバッファ データをより高速でアクセスできる場所に置く 演算バッファ 時間のかかる演算の処理結果を保存する 25
26 課題に対して 適切なバッファリングを選択すること
27 ケーススタディ
PHPウェブアプリケーションの改善 28
29 DB クエリ結果のキャッシュ データベースの問い合わせ結果を KVS にキャッシュ ウェブアプリケーションで最 もよく使われる Cache の
パターン
30 プロファイラー Xhprof, Datadog, New Relic 計測できれば何でもOK
レイテンシを分析 31 その処理時間は データIO ??? 演算 ???
レイテンシを分析 2 32 この例では データIO と 演算 を キャッシュを使うことで削減
設計のポイント - 計測して、レイテンシーの中身を分析 - バッファにより何を改善するのかを明確化 33
34 落とし穴
35 距離が変わらない Cache Redis 10,000 GET 600 ms MySQL 10,000
SELECT 800 ms 演算がボトルネックではない上に データIOも距離が変わってない
36 距離が変わらない Cache Redis 10,000 GET 600 ms MySQL 10,000
SELECT 800 ms 演算がボトルネックではない上に データIOも距離が変わってない レスポンスタイム向上が目的だとしたら失敗 DBコネクション数の削減なら成功 → 目的がとっても大事
IOバッファは距離が大事 - 元の処理の距離 - 改善後の処理の距離 37
PHP で使える Cache とレイテンシ - データベース 500 μs - Redis
(KVS) 500 μs - ファイル 16 μs - メモリ 100 ns ( 0.1 μs) 38
39 レイテンシーの表 https://colin-scott.github.io/personal_website/research/interactive_latency.html
40 レイテンシーの表 https://colin-scott.github.io/personal_website/research/interactive_latency.html ネットワーク ファイル メモリ
41 距離を変える Redis 10,000 GET 57 ms MySQL 10,000 SELECT
800 ms 距離を変えたので IO バッファが効い た
おさらい Cache を使ったバッファリングで速度改善できるのは - 演算処理 - IO処理 何を改善したくて Cache を使うのか?
まず計測をした上で 明確な目的 を持つこと 42
おまけ 43
44 落とし穴2
Cache は要注意 - 古い情報の Cache - Cache ストアの可用性 - サンダリングハード
45
参考情報 - Webサービスにおける キャッシュ戦略 - Speaker Deck https://speakerdeck.com/yusukebe/websabisuniokeru-kiyatusiyuzhan-lue - Webアプリケーションのキャッシュ戦略とそのパターン
- Speaker Deck https://speakerdeck.com/moznion/pattern-and-strategy-of-web-application-caching 46
47 落とし穴3
48 Cache しないで済むなら しないに越したことはない
PHP における Cache の注意点 - Serialize, Unserialize のコスト - Cache
機構自体が備える安全担保のコスト 巨大データをキャッシュしても、データ取得後の unserialize にコストがか かるので、キャッシュの旨味が少ないときがある 49
Cache による処理時間削減は 0 じゃない 50 ここで Cache 取得にまつわる コストが発生している
51 絶対に計測して確認すること!
immutable_cache 52 https://pecl.php.net/package/immutable_cache apcu からメモリへの値コピーを 除外したもの
配列1件を cache → 10,000 回取得 - apcu 55msec - immutable_cache
55msec 性能は変わらない 53
配列5000件を cache → 10,000 回取得 - apcu 6.4 sec -
immutable_cache 67 msec 実測することで、cache 処理自体への理解も進む 54
55 落とし穴4
メモリ Cache の注意点 - 複数台構成だと Cache アウトを制御しづらい - サーバーA では最新、サーバーB
では古いなどが発生 キャッシュの新旧チェックや、生存期間を考慮する必要がないデータに限 定するなど、工夫が必要 56
@hanhan1978 相談・指摘・その他 下記のTwitterアカウントにどうぞ 57