タグ

関連タグで絞り込む (15)

タグの絞り込みを解除

cacheに関するfumikonyのブックマーク (10)

  • リクエストヘッダーに基づいてコンテンツをキャッシュする - Amazon CloudFront

    CloudFront により、ヘッダーをオリジンに転送し、ビューワーリクエストのヘッダー値に基づいて異なるバージョンのオブジェクトをキャッシュするかどうかを選択できます。こうすることで、ユーザーが使っているデバイスの種類やビューワーの場所、ビューワーで使われている言語など、さまざまな条件に基づいてコンテンツの異なるバージョンを配信できます。 ヘッダーとディストリビューションの概要 デフォルトで、CloudFront では、エッジロケーションでオブジェクトをキャッシュする際にヘッダーが考慮されません。オリジンが 2 つのオブジェクトを返し、そのリクエストヘッダーの値のみが異なる場合、CloudFront はオブジェクトの片方のみをキャッシュします。 ヘッダーをオリジンに転送するように CloudFront を設定できます。その場合、CloudFront は 1 つ以上のリクエストヘッダーの値

  • CloudFrontのキャッシュ時間(TTL)はどの程度なのか | DevelopersIO

    よく訓練されたアップル信者、都元です。 CloudFrontはContents Delivary Network、所謂CDNですが、ざっくりと言ってしまえば、要するにキャッシュ機能を持ったHTTPリバースプロキシです。CloudFrontでは、元々のコンテンツ提供をするサーバのことをオリジンと呼びます。 CloudFrontでは、オリジンから提供されるコンテンツを、エッジサーバと呼ばれる世界各地に点在するコンテンツ配信専用のサーバ上にキャッシュすることによって、高い転送速度パフォーマンスを発揮しています。しかし、キャッシュというのはオリジン上のコンテンツの更新があった時に、内容が乖離してしまうという問題があります。 通常、CloudFrontは静的コンテンツ *1の配信に利用します。しかし、静的なコンテンツではあるのですが、定期的にファイルの差替えを行う、という可能性が無いわけではありませ

    CloudFrontのキャッシュ時間(TTL)はどの程度なのか | DevelopersIO

  • cachectld〜無駄なページキャッシュの削除を自動化〜 | メルカリエンジニアリング

    原稿の執筆が一段落して心に余裕が出てきた@cubicdaiyaです。 今回はサーバを運用しているとありがちなページキャッシュに関する問題とメルカリのアプローチについて解説します。 Fluentdによるログ転送 話は変わりますが、メルカリの各サーバ上ではプログラムが吐いたログデータをKibanaやNorikraといった各種コンポーネントに転送するためにFluentdが稼働しています。各ログデータは原則単一のファイルに追記されてFluentdのtailプラグインによって各所に転送されていきます。 ログデータのサイズはまちまちで、1日で数GB程度のログデータもあれば数十GB以上のログデータもあります。 ページキャッシュと巨大なログファイル 各サーバに吐かれるログデータのサイズはサーバに搭載されているメモリのサイズと比べると1日分だけでもかなりの量になります。そして、このように絶えず書き込まれる巨

    cachectld〜無駄なページキャッシュの削除を自動化〜 | メルカリエンジニアリング

  • Webアプリケーションのキャッシュ戦略とそのパターン / Pattern and Strategy of Web Application Caching

    YAPC::Kansai OSAKA 2017の資料です

    Webアプリケーションのキャッシュ戦略とそのパターン / Pattern and Strategy of Web Application Caching

  • IPA ISEC　セキュア・プログラミング講座：Webアプリケーション編　第5章 暴露対策：プロキシキャッシュ対策

    第5章 暴露対策 プロキシキャッシュ対策 プロキシキャッシュへのコンテンツ残留 ブラウザとWebサーバの間には、いくつかのキャッシュメカニズムが働いていることが多い。 プロキシサーバのキャッシュ──企業等LANを運用している多くの組織体ではLANからインターネットアクセスを行う際プロキシサーバを経由して行うことが多い キャッシュサーバ─インターネットプロバイダの中には、会員のWebアクセスを円滑にする目的でキャッシュサーバを運用しているところがある これらのキャッシュメカニズムは、ブラウザからのリクエストによって得られたコンテンツをキャッシュに保持しておき、同じURLのリクエストが生じたとき、本来のWebサーバにコンテンツを取りに行かず、キャッシュの内容をブラウザに渡すものである。 このようにキャッシュは、円滑なインターネットの利用に寄与してくれる。 しかし、コンテンツによっては、ただひと

  • ブラウザのキャッシュコントロールを正しく理解する - Qiita [キータ]

    ①ブラウザに一切、キャッシュさせたくない場合 サーバからクライアントへのHTTP応答ヘッダ → Cache-Control "no-cache" アクセス毎に内容が変わったり、サーバにアクセスしてもらわないと困るようなコンコンテンツの場合です。 スクリプト言語等で生成する動的コンテンツは、このようにした方が安全です。 例えば対象コンテンツが画像である場合、ブラウザで同じ画像のURLが含まれたHTMLを開いた場合は、 もちろんローカルにキャッシュがないので、サーバへ問い合わせを行う 条件つきリクエスト（If-Modified-Since、If-None-Match）もサーバへ送ってこない ②ブラウザにキャッシュさせるけど、変更ないか都度確認するようにしたい サーバからクライアントへのHTTP応答ヘッダ → Cache-Control "max-age=0" → Expires "Mon, 2

    ブラウザのキャッシュコントロールを正しく理解する - Qiita [キータ]

  • Stale-While-Revalidate ヘッダによるブラウザキャッシュの非同期更新 | blog.jxck.io

    Intro システムにおいてキャッシュの設計は永遠の課題であり、 Web のパフォーマンスにおいても非常に重要である。 Web では、 HTTP ヘッダを用いてブラウザやプロキシにキャッシュの制御を指定する。 Stale-While-Revalidate ヘッダは、このキャッシュ制御に選択肢を追加する新しい仕様である。 このヘッダの概要と、本サイトへの適用を解説する。 Web におけるキャッシュ キャッシュの種類 まず、ブラウザが持つ従来のキャッシュの機構について整理する。 そもそも、キャッシュを行う意義は大きく二つある。 リソースの取得を高速化する サーバへの負荷を減らす これまでは HTTP ヘッダを用いて、キャッシュを管理させる方法を用いてきた。 Web における、キャッシュの指定には大きく二つの方式がある。 ブラウザはリクエストを発行せず、保持するキャッシュを使用する(Cache-

    Stale-While-Revalidate ヘッダによるブラウザキャッシュの非同期更新 | blog.jxck.io

  • Nginxで特定ページのキャッシュクリアする - Qiita

    find /var/cache/nginx/example.com -type f -exec grep -l "KEY: http://example.com/$" {} \; | xargs rm -f

    Nginxで特定ページのキャッシュクリアする - Qiita

  • Webアプリにおけるキャッシュ。オレオレ事例 - ゆーすけべー日記

    Webアプリにおいて、アクセスやデータ量が多く/大きくなってくると、 バックエンドのパフォーマンスが低下しがちです。 MySQLなどのRDBMSにデータを置いている場合は適切に クエリーを改善する、インデックスを張る、といった策で解決する場合もありますが、 キャッシュを効果的に利用することでより高負荷に対応できる可能性があります。 また、外部APIへの問い合わせなど、どうしてもネットワークや他のリソースのレスポンスタイムに 引きずられる部分に関しては情報を手元にキャッシュしておくと何かとよいでしょう。 今回はWebアプリケーションのレイヤーで最近僕がどのようにキャッシュを使っているのか？ の事例を紹介しつつまとめてみたいと思います。 キャッシュについてとその基本 そもそもキャッシュとは、簡単にふわっと表現するならば、 「一時的に情報を手元の近い場所に置いておいて利用する手法、もしくはその一

    Webアプリにおけるキャッシュ。オレオレ事例 - ゆーすけべー日記

  • Module ngx_http_proxy_module

    Makes outgoing connections to a proxied server originate from the specified local IP address with an optional port (1.11.2). Parameter value can contain variables (1.3.12). The special value off (1.3.12) cancels the effect of the proxy_bind directive inherited from the previous configuration level, which allows the system to auto-assign the local IP address and port. The transparent parameter (1.1

    Module ngx_http_proxy_module
  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.