Web 技術解体新書「第二章 Cache 解体新書」リリース
Web 技術解体新書「第二章 Cache 解体新書」リリース Intro 「Web 技術解体新書(Web Anatomia)」の第二章として「Cache 解体新書(Cache Anatomia)」をリリースしました。 これで予定している八章のうち二章が終わりました。 第一章: Origin 解体新書 第二章: Cache 解体新書 Cache 解体新書 以下の Response Header Field がどういう意味を持つか正確に説明できますか? おそらく多くの Web 開発者が一度は見たことがあり、これを「1 時間キャッシュする」という意味で指定している人もおおいでしょう。 では、どこから 1 時間で、 1 時間経ったらなにが起こるのか、これが Response でなく Request に付与されたらどう変わるのか、きちんと把握できていますか? そもそも、一般的にキャッシュ機構における
Back/forward cache | Articles | web.dev
Check out this video of bfcache in action to understand the speed up it can bring to navigations: Using bfcache makes pages load much more quickly during back and forward navigation. In the video, the example with bfcache is quite a bit faster than the example without it. bfcache not only speeds up navigation, it also reduces data usage, since resources don't have to be downloaded again. Chrome us
はてなブログのキャッシュ周りをきちんと改善したら、アプリケーションサーバの台数を半分にできた話 - Hatena Developer Blog
はてなブログでSREをやっているid:cohalzです。 2019年12月頃からid:utgwkkやid:onkとともに、はてなブログにおけるキャッシュ周りの改善を行いました。その結果、次のような成果が得られました。 ブログ記事のキャッシュヒット率が、1日平均で8％から58％に向上 アプリケーションサーバの台数を、以前の半数以下に削減 DBに届くリクエスト数が、以前の3分の2まで減少 レスポンスタイムの平均が、以前の8割まで減少 この記事では、実際にどういった改善を行ったのか、その際に気をつけたことや大変だったことを紹介します。 はてなブログがVarnishを導入した経緯と課題 開発合宿をきっかけに問題が明らかになる 進め方をまず考える ホストのメモリをできるだけたくさん利用する メモリを積んだホストでなぜかレイテンシが悪化 キャッシュが分散しないようVaryヘッダを使う デバイス情報を適
Apollo のキャッシュ機構、完全に理解した(い) - JX通信社エンジニアブログ
この記事は JX 通信社アドベントカレンダー、GraphQL アドベントカレンダーの4日目です こんにちは、JX通信社の小笠原(@yamitzky)です。普段はエンジニア部門の統括をしています。 弊社の NewsDigest ではアプリ向けのバックグラウンド API として GraphQL を使っています(サーバーは gqlgen、アプリはライブラリなし)。 tech.jxpress.net GraphQL の技術スタックとしては Apollo というライブラリが有名だと思うのですが、弊社では使ったことがありませんでした。そこで、今年の 9 月に箱根で開催した開発合宿にて、Apollo Client(React) と Apollo Server の検証を行いました。 Apollo Client を使うときに唯一鬼門だったのが、Apollo の持っているキャッシュ機構です。本日は、Apoll
Cache-Control の Immutable 拡張によるリロード時のキャッシュ最適化 | blog.jxck.io
Intro ブラウザはリロード時に、max-age に満たないキャッシュを持っていても Conditional GET によってキャッシュの Validate (有効性の問い合わせ)を行う。 Cache-Control Extension として提案されている Immutable 拡張は、キャッシュが max-age 内であればリロード時もキャッシュヒットさせる拡張である。 このヘッダの効果と、本サイトへの適用について記す。 Cache-Control Cache-Control に max-age を指定することで、ブラウザにリソースをキャッシュさせることができる。 このキャッシュは max-age の期間内は fresh とみなされ、fresh であればサーバへの問い合わせなく再利用される。 サーバへの問い合わせ(RTT)が無いため、事実上最速のリソース取得となる。 Reload しか
Webサービスにおける
キャッシュ戦略
YAPC::Asia Hachioji 2016 mid in Shinagawa 2016-07-03 Yusuke Wada a.k.a. yusukebe
Auto ScalingではなくてAuto Cachingという考え方 - Copy/Cut/Paste/Hatena
今年の3月くらいからずっと悶々としていて、なかなか手が出せなかったアイデアがやっと実現できました。 mod_mrubyでやりたいことできたー！— k1LoW (@k1LoW) June 16, 2016 （試行錯誤して書いてみたら、結果たった数行という。。。） Auto ScalingではなくてAuto Cachingという考え方 AWSではAuto Scalingという、サーバの負荷の変化などによってEC2インスタンスをスケールする便利な機能があります。 が、大抵はクラウド環境でないと容易には実現できません。 例えば、クラウドではなく サーバリソースは増やせない。 普段はキャッシュはしてほしくないコンテンツ。 ただ、アクセスが多くなるとかで何かしら負荷が高くなった時には「仕方なく」キャッシュを使っても良い。落ちるよりはマシ。 負荷が戻ったらキャッシュを使わないようにして欲しい。 という状
Fastly CDN が便利そうだったので Azure と使ってみた - しばやん雑記
The edge cloud platform behind the best of the web | Fastly Azure にも EdgeCast を使った CDN が用意されていますが、未だにキャッシュしたコンテンツの Purge すら出来ないので、150ms 以下という超高速でキャッシュの Purge が可能な Fastly を試しました。 Fastly の Instant Purge はとても速いので、これまでは CDN が使えなかった動的に変化するコンテンツでもキャッシュ出来るようになります。それらを Fastly ではイベント駆動コンテンツと呼んでいるようです。 The Rise of Event-Driven Content | Fastly 利用する上で、この記事は必読です。ドキュメントには API でも CDN を有効にする手順もあります。 Enabling API
Railsアプリを66％スピードアップ ― Railsキャッシュの完全ガイド | POSTD
(訳注：2016/3/2、頂いた翻訳フィードバックをもとに記事を修正いたしました。) Railsアプリでのキャッシングは、「たまに夕食を一緒にするけれど、本当はもっと頻繁に一緒にいるべき友達」に少し似ています。パフォーマンスをまじめに考えるRailsアプリのほぼ全てで、もっとキャッシングを使えるはずですが、ほとんどのRailsアプリでは、完全にキャッシングを避けています。それでも普通は、Railsで高速なサーバ応答を達成するための唯一の道は、キャッシングの知的な利用なのです。約250msの応答時間を、簡単に50～100msに高速化できます。 定義についての注意 ― この記事は、アプリケーション層のキャッシングのみを対象としています。HTTPキャッシング（これは全く別の難物で、あなたのアプリケーションに実装する必要はありません）は、別の機会で扱いましょう。 するべきキャッシングをしない理由
Node.jsでキャッシュ機構をつかう - 尋常でないもふもふ
isaacs/node-lru-cache · GitHub が便利。 Java でいうと Ehcache みたいに使える。ただ、Ehcache はキャッシュアルゴリズムを指定できるが、 lru-cache は LRU（Least Recently Used）という名の通り、最近のもっとも使われていないデータを最初に捨てるアルゴリズム専用。 インストール npm install lru-cache 初期設定 var LRU = require("lru-cache"); var options = { max: 500, //キャッシュの最大件数 maxAge: 24 * 60 * 60 * 1000 //保存期間の指定、単位はミリ秒 } var cache = LRU(options); 使い方 保存 var key = 'user_100'; var value = { user_id
pixivでBloomFilterを使うためにやったこと - pixiv inside [archive]
こんにちは。最近はAndroidアプリ開発に入門しました、@edvakfです。 pixivではキャッシュ兼汎用KVSとしてKyotoTycoon (KT)を使用しており、頻繁にアクセスされるキーはアプリケーションサーバー内のAPC（PHPのshared memory cacheです）にもキャッシュすることで多段化しています。 このような構成の弱点として、「ほとんどの場合は値が無いけど毎回存在確認が必要なキー」の場合に前段にキャッシュが無くて毎回後段にまで問い合わせなければいけないという問題があります。ネガティブキャッシュ（値がないことをキャッシュする）を使うという手もありますが、問い合わせるキーの数が膨大になってくると現実的ではありません。 pixivでは、作品に付いている最大10個のタグについて、ピクシブ百科事典に記事があるかどうかを判定する必要がありました。これに加え、最近ではBOOT
![pixivでBloomFilterを使うためにやったこと - pixiv inside [archive]](https://cdn-ak-scissors.b.st-hatena.com/image/square/2a12b3c2014efe525d7051ddf729e9203e7d2989/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2Fe1a98c57eedebf79f461204e2f9521a51faba3ca%2Fbackend%3Dimagemagick%3Bversion%3D1%3Bwidth%3D1300%2Fhttp%253A%252F%252Fcdn-ak.f.st-hatena.com%252Fimages%252Ffotolife%252Fd%252Fdevpixiv%252F20140722%252F20140722045434.png)
ssig33.com - Rails アプリでのビューキャッシュ戦略
キャッシュでレンダリングコストケチっていかないといけないようなことになってる時点でビジネスとして成立してないので撤退を検討したほうがいいと思う。 殆どスタティックな記事を配信して動的な部分は JS でやるとかあるけど、結局それってサーバー代を使わないかわりに膨大なエンジニアリングコストを使うことになる。意味ない。 予想外の形でサービスがヒットした結果酷い状態のコードをなんとか飛ばし続けないといけないこともあってその場合はとりあえずキャッシュを導入して時間かせぎをしつつビューをまともにしていくとかそんなことになると思う。けどその場合そこに「戦略」なんてものがあることはなくてひたすら泥縄的な対処が繰り広げられる。 何か問題がある時にとりあえずキャッシュで本質的な解決が得られるということはないので、データ構造を直していくとか、よい CPU を買うとかもっと本質的な解決法が重要。重ねて言いますがよ
DMM inside
“爆速” 導入の舞台裏！デジタル庁が提供する「デジタル認証アプリ」の活用で実現「安全で簡単な本人確認システム」
PHP5.5 のコードキャッシュは APC から Zend OPcache へ
PHP5.5 からコードキャッシュとして標準バンドルされた Zend OPcache を試してみました。 第6回関西PHP勉強会で Zend OPcache についてLTしたのでインストールやベンチマークなどはこちらで。 beta4時点では、Zend OPcache は拡張で提供され、opcache.so インストールされる。 Zend OPcache を使うには、php.ini で zend_extension=opcache.so の記述が必要。 やっぱりデフォルトでインストールされるのは楽。 PHP5.5リリースと共に使えるので安心。（PHP5.4 対応の APC はまだ beta） ユーザデータのキャッシュはできないので、別の方法が必要。 OCP – OPcache Control Panel Zend OPcache の利用状況（設定、キャッシュ量など）が確認できるスクリプトが
pixivのデータストア/キャッシュ戦略 その2 - pixiv engineering blog
先月末にwww.pixiv.netのバージョン管理をSubversionからGitに移行できてホッとしているインフラ兼ソフトウェアエンジニアのbokkoです。 pixivのSubversionリポジトリには＼( ^ o ^ )／ディレクトリなるものが存在していて、開発が終了したプロジェクトやもう使われなくなったソースコードはremoveされるのではなく、 この＼( ^ o ^ )／ディレクトリにmoveされます。 www.pixiv.netもGitに移行した後、{trunk,branches,tags}のすべてを＼( ^ o ^ )／へmoveしましたが、あまりにも巨大過ぎて「svn move -> commit」が完了するのに1時間半かかりました。おそらく僕の人生の中で最も時間のかかったコミットとして全僕の中で語り継がれるのではないかと思います。 最近は弊社でも「最初に触れたバージョン管
Webアプリにおけるキャッシュ。オレオレ事例 - ゆーすけべー日記
Webアプリにおいて、アクセスやデータ量が多く/大きくなってくると、 バックエンドのパフォーマンスが低下しがちです。 MySQLなどのRDBMSにデータを置いている場合は適切に クエリーを改善する、インデックスを張る、といった策で解決する場合もありますが、 キャッシュを効果的に利用することでより高負荷に対応できる可能性があります。 また、外部APIへの問い合わせなど、どうしてもネットワークや他のリソースのレスポンスタイムに 引きずられる部分に関しては情報を手元にキャッシュしておくと何かとよいでしょう。 今回はWebアプリケーションのレイヤーで最近僕がどのようにキャッシュを使っているのか？ の事例を紹介しつつまとめてみたいと思います。 キャッシュについてとその基本 そもそもキャッシュとは、簡単にふわっと表現するならば、 「一時的に情報を手元の近い場所に置いておいて利用する手法、もしくはその一
Application Cacheの割と実践的な使い方 - 愛と勇気と缶ビール
これもしばらく昔に調べたものだけど、どうせなので書いておく。調べた当時、あまりこういう情報は見当たらなかったので。 HTML5というすごく大雑把で、具体的にどの技術を指しているのかよく分からないままに広告とプロパガンダに使われる技術用語、その内に含まれると考えられている技術の中でも特殊な立ち位置と振る舞いを持ったApplication Cacheについては、検討して「ああこれはよく分からん」「ああこれは使えない」と思って利用を諦めてしまった人も多いことと思われる。 僕も真面目にリアルのサービスでモリモリ使っております、という訳ではないのでとても偉そうなことは言えないのだが、前に利用の検討をした時に思ったのは「これは既存のWebサービスに後付けするようなものではなく、初めからその存在を前提としてサービスを作るときに意味のあるものだなぁ」ということだった。 既存のWebサービスに乗っける上で特
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Webアプリケーションのキャッシュ戦略とそのパターン / Pattern and Strategy of Web Application Caching
DeNA Engineering - DeNAエンジニアのポータルサイト
nginxのproxy_cache_keyのデフォルト - Qiita
