![Webアプリケーションのキャッシュ戦略とそのパターン / Pattern and Strategy of Web Application Caching](https://cdn-ak-scissors.b.st-hatena.com/image/square/800508fdd89c7edd399a09a2ac8192248b78b7b8/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F46655138974643fca0c29eb58200b6fa%2Fslide_0.jpg%3F7629884)
「PageSpeed Insights」でサイトの速度アップについて「ブラウザのキャッシュを活用」提案され、そのリンク先を確認すると下記のように記述されています。 『●Expires ヘッダーと Cache-Control: max-age ヘッダー これらのヘッダーでは、ウェブ サーバーから新しいバージョンが提供されているかどうか確認せずに、ブラウザでキャッシュ済みのリソースを使用できる期間を指定します。無条件で適用される「強いキャッシュ ヘッダー」です。設定後にリソースがダウンロードされると、有効期限や最大期間に達するかユーザーがキャッシュを消去するまで、ブラウザはそのリソースに対する GET リクエストを発行しません。 ●Last-Modifed ヘッダーと ETag ヘッダー これらのヘッダーでは、キャッシュする目的で、ファイルが同じかどうかをブラウザが判断する方法を指定します
今回は既にCDNを利用している方も、利用していない方も今すぐ出来るHTTPヘッダチューニングをご紹介します HTTPヘッダのお話では、レスポンスヘッダやリクエストヘッダの中に何があり、どういう役割なのか簡単にまとめてみましたが、非常に多くのデータがWEBのやりとりで利用されていることが分かったと思います。 CDN利用時に利用者側が出来るチューニングは、オリジンサーバー側のApacheやNginxなどでどのようなHTTPレスポンスヘッダを付与するのか、しないのかということを決めるヘッダチューニングです。 Last-ModifiedヘッダはレスポンスヘッダのひとつでApacheやNginxなどのWEBサーバー側で適切な設定をすることによって、ブラウザ側にコンテンツの最終更新時刻を送信することができます。 ブラウザ側は、このコンテンツの最終更新時刻を覚えておき次回リクエストした際にリクエストヘッ
前回のエントリ(ブラウザのキャッシュコントロールを正しく理解する)でブラウザ側のキャッシュ制御について説明しました。 ただ動的スクリプトなら、次の例のようにHTTPレスポンスヘッダを操作すればいいのですが、 <?php header('Content-Type: text/plain; charset=UTF-8'); header('Cache-Control: max-age=0'); echo "Hello World!"; ?> スクリプトを介さない静的リソース(HTMLファイル、JSファイル、CSSファイル、画像ファイルなど)はどうやってHTTPレスポンスを操作すればいいかというと、もしApacheを利用している場合は mod_header と mod_rewrite を利用して次のように簡単に出来ます! 設定例 想定ケースとして、次のようにブラウザ側のキャッシュを制御したいと仮
①ブラウザに一切、キャッシュさせたくない場合 サーバからクライアントへのHTTP応答ヘッダ → Cache-Control "no-cache" アクセス毎に内容が変わったり、サーバにアクセスしてもらわないと困るようなコンコンテンツの場合です。 スクリプト言語等で生成する動的コンテンツは、このようにした方が安全です。 例えば対象コンテンツが画像である場合、ブラウザで同じ画像のURLが含まれたHTMLを開いた場合は、 もちろんローカルにキャッシュがないので、サーバへ問い合わせを行う 条件つきリクエスト(If-Modified-Since、If-None-Match)もサーバへ送ってこない ②ブラウザにキャッシュさせるけど、変更ないか都度確認するようにしたい サーバからクライアントへのHTTP応答ヘッダ → Cache-Control "max-age=0" → Expires "Mon, 2
I heard recently that Nginx has added caching to its reverse proxy feature. I looked around but couldn't find much info about it. I want to set up Nginx as a caching reverse proxy in front of Apache/Django: to have Nginx proxy requests for some (but not all) dynamic pages to Apache, then cache the generated pages and serve subsequent requests for those pages from cache. Ideally I'd want to invalid
・・で前回の話の続きをここに書くわけですが。結果を書かなかったのは、本当にこの手順でいいのか?というのが 若干不安だったためです。でも現状これで稼働しており。キャッシュも取れ、パフォーマンスも確保しているので掲載したいと思います。 あくまでも、私のメモ!!レベルです 設定は、nginx.conf と default.conf の2種類になります まるっとconfファイルを掲載しましたが、CDNを作る上で重要な部分だけを抜粋します。 /etc/nginx/nginx.conf 設定すべき項目は以下の項目です。こちらは、キャッシュ全般の設定を行っております proxy_cache_path /var/cache/nginx/cache levels=1:2 keys_zone=my-key-zone:64m max_size=180000m inactive=4d; level # level
nginxでproxy_cache_pathにしているkey_zoneのサイズはどのくらいにすれば良いのか。 nginxでプロキシキャッシュを使う場合はnginx_cache_pathにパスや容量などを指定する事になる。 proxy_cache_path /var/lib/nginx/cache levels=1:2 keys_zone=CACHE:512m inactive=1d max_size=60g; このときkeys_zoneには共有メモリの名前と容量を指定するのだが、この容量は結局の所幾らにすればよいのか。引用すると次のようになるらしい。 Zone size should be set proportional to number of pages to cache. The size of the metadata for one page (file) depends on
こんにちはこんにちは。11インチMacBook Airが欲しくてたまらないiwanagaです。 前回の記事 が幸いにもご好評を頂けた様で非常にうれしいです。嬉しくなって、ついがんばって第2弾を書いてしまいました。引き続き、ソーシャルゲームでよく使われるテーブルタイプ毎にちょっとしたテクニックを紹介していきます。 今回はちょっとライトな感じ&読み物になってしまっていますが「ユーザID単位で1つだけ持つデータ」と「パラメータなどのマスターデータ」についてご説明したいと思います。ちなみに次回はInnoDBのデータ構造の簡単な説明と複合プライマリーキーのデータについて、その次で紹介し損ねたちょっとマニアックなテクニックや性能管理のための手法を紹介することを予定しています。 その前に。。。 先日行われた JAPAN INNOVATION LEADERS SUMMIT で弊社松信が「ソーシャルゲームの
HeartRails Tech Blog ハートレイルズのエンジニア、デザイナーによるブログです。 ウェブサービス、スマホアプリ、IoT デバイスの開発に関連する技術的な情報を発信していきます。 この記事は、そろそろ一般向けにサービスリリースしてみようかなと考えているエンジニア向けに書きました。 説明に Rails を用いていますが、考え方自体は Web アプリ一般に応用可能です。 結論 「cache publicに設計しよう」 出来るだけ多くのページを cache public にしましょう。 砲撃の来るページは cache public に出来るはずです。 この説明だけで意味の分かった方には以下の記事は読む価値はありません。時間を有意義につかってください。ごきげんよう。 砲撃に耐えよう サービスリリースして、バグもなく順調に事が運び、運が良ければバズったり、どこぞの大手メディアに取り上
アプリケーションをデプロイした後、利用者から「リロードしてもデータが最新にならない」「更新したはずのデータが書き変わらない」というクレームを受けたので調べてみると以下のようなログが出ていた。 データの更新後、$location.path("/path")内部パスを変える処理を行っているのだが、パスを変えた後のGETリクエストが全てHTTP 204で返って来ていることが分かる。(後で調べるとと304の時もあった) 普段、開発とテストに使用しているChromeでは見たことが無いので、UAを調べると案の定IE(IE10、IE11)だった。 調べてみるとIE(少なくとも10と11)はAjaxのリクエストを勝手にキャッシュするようで、このログが表示されている間はサーバに全く問合せに行っていなかった。 この問題(IEだけのようだが)解決するにはHTMLのヘッダーのようにリクエストのヘッダを明示的にキャ
最近色々あってAndroidと心を通わせられるようになってきたago(@kyo_ago)です。 このエントリは tech.kayac.com Advent Calendar 2012 3日目の記事です。 Application cache(cache manifest)とは WHATWGやW3で議論されているHTML5 Offline Web Applicationの仕様の一部です。 細かい仕様等に関しては最後に参考URLをつけたのでそちらをご覧ください。 ここでは色々誤解の多いApplication cacheの使い方をご紹介したいと思います。 使い方 .appcacheの拡張子に対してtext/cache-manifestのMIMEタイプを設定してください。 .appcacheファイルは以下の形式で作成してください。 CACHE MANIFEST: #更新用ID(日付+連番等) キャッ
第5章 暴露対策 プロキシキャッシュ対策 プロキシキャッシュへのコンテンツ残留 ブラウザとWebサーバの間には、いくつかのキャッシュメカニズムが働いていることが多い。 プロキシサーバのキャッシュ──企業等LANを運用している多くの組織体ではLANからインターネットアクセスを行う際プロキシサーバを経由して行うことが多い キャッシュサーバ─インターネットプロバイダの中には、会員のWebアクセスを円滑にする目的でキャッシュサーバを運用しているところがある これらのキャッシュメカニズムは、ブラウザからのリクエストによって得られたコンテンツをキャッシュに保持しておき、同じURLのリクエストが生じたとき、本来のWebサーバにコンテンツを取りに行かず、キャッシュの内容をブラウザに渡すものである。 このようにキャッシュは、円滑なインターネットの利用に寄与してくれる。 しかし、コンテンツによっては、ただひと
ブラウザキャッシュとレスポンスヘッダの関係を調べてみた。 調べたブラウザ Firefox 3.5 IE 6 Opera 9.64 Google Chrome 2.0.172.33 レスポンスヘッダ Expires Last-Modified Cache-Control Pragma 結論 以下のレスポンスヘッダを返す。 Expires、Last-Modified、Cache-Control、Pragma 以外のヘッダについては任意。 キャッシュさせたい場合 Cache-Control: private, max-age=有効期間の秒数 条件付GETをさせたい場合 Expires: 過去の時刻 Last-Modified: 過去の時刻 キャッシュさせたくない場合 Cache-Control: no-cache 調査方法 それぞれのブラウザで以下のレスポンスヘッダを返すページを読み込んだときに
August 23, 2008 10:51 am | 13 Comments It’s important to make resources (images, scripts, stylesheets, etc.) cacheable so your pages load faster when users come back. A recent study from Website Optimization shows that the top 1000 home pages average over 50 resources per page! Being able to skip 50 HTTP requests and just read those resources from the browser’s cache dramatically speeds up pages.
HHKB Professional Type-Sが欲しいインフラ兼ソフトウェアエンジニアのbokkoです。 普段はHHKB Proの日本語配列キーボードを愛用しています。英語配列は苦手です。このことを同僚のエンジニアに言うとジト目で見つめられ・・・睨みつけられること請け合いです。 本連載の最後となる今回はpixivのデータストア/キャッシュ戦略を支える周辺ミドルウェアについて解説していきます。 memcachedからKyotoTycoonへ移行した際に発生した問題 前回の記事の最後にもあったようにpixivではAPの数だけあったmemcachedへのリクエストを少数のKyotoTycoonにまとめたことで一部のKyotoTycoonサーバへのTCPコネクション数が爆発してKyotoTycoonサーバのCPUやメモリリソースには余裕があるのにネットワークで詰まるという問題が起こりました。 元
ふとDjango 1.3 beta1を触ってみたら、今までのCACHE_BACKENDという設定に変わって、CACHESという設定が可能になった。これを使うと複数のキャッシュを指定できる。 # settings.py CACHES = { 'default': { 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache', 'LOCATION': '127.0.0.1:11211', }, 'alternative': { 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache', 'LOCATION': '127.0.0.1:11212', } } django.core.cache.get_cacheでキャッシュソース名を指定してキャッシュオブ
Djangoのキャッシュを使ってみたが良いなー 今回は、 Djangoの「低水準のキャッシュ API」を使って、 キャッシュを取ることにしてみた。 これ抜群に良いな。 必要な部分(サイトバーやメイン部分の一部など)やオブジェクト丸ごとキャッシュしてやったりと、 色々出来る。 各ユーザーごとにページがある場合なんかは、 そのユーザーごとにキャッシュを取るようにしてあげるなんて事をやってみた。 今回はローカルメモリ上に残すのをやってみる。 まずは、 settings.pyに以下を加える。 Djangoオンラインドキュメント和訳に載っていたが、 このキャッシュはマルチプロセスセーフかつスレッドセーフ 良いねー。 次にキャッシュを実際に保存する部分 今回は全てviews.pyで行った。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く