タグ

cacheに関するkoko1000banのブックマーク (18)

  • cache conflict - 未来のいつか/hyoshiokの日記

    id:hyoshiok:20050825 の続き。アプリケーションレベルでハードウェアキャッシュを意識することはまあそうそうないが(それよりも計算量の少ないアルゴリズムを考えろつーことだ)OSだとその手のことをいろいろ考えないといけない場合が多くなってきた。spinlockなんかはメインメモリに必ずアクセスしに行くのでコストの高いオペレーションだということがよく知られているし、ロック競合を減らすためにもspinlockをいかにして減らすかということがカーネルプログラマの興味の中心(?)だったりもする。 とはいうものの、多くのプログラマはハードウェアキャッシュのことを意識していない。例えば、メモリに対するアクセスコストは等価だと仮定してプログラミングするが、(多くの場合はそれで十分なのだけど)、ハードウェアキャッシュとメインメモリへのアクセスは100倍以上コストが違う。メモリアクセスは非常に

    cache conflict - 未来のいつか/hyoshiokの日記
  • ファイルがページキャッシュに乗っているかどうかを調べる - ablog

    Linux上で任意のファイルがページキャッシュに乗っているかどうか調べるCで書かれたプログラムを見つけたので、コンパイルして実行してみた。 Linux上のとあるファイルがページキャッシュに乗っているかどうかを調べたいなーと思ってGoogle先生にご相談したところ、こんなコマンドを教えてくれた。 ファイルをメモリにマップして、mincore(2)でページごとにRAMに存在するかどうかをチェックしているらしい。 mmapしても即メモリにロードされるわけではないのかぁ。 Cの部分だけ抜き出して、単体で動かしてみた。 #include <errno.h> /* errno */ #include <fcntl.h> /* fcntl, open */ #include <stdio.h> /* perror, fprintf, stderr, printf */ #include <stdlib.

    ファイルがページキャッシュに乗っているかどうかを調べる - ablog
  • 開発メモ: Kyoto Tycoonの設計 その壱

    memcachedのように一時的なデータを高速に扱えながらもデータをファイル上に永続化できるサーバとして、「Kyoto Tycoon」という製品を開発することにした。もちろん、Kyoto Cabinetをストレージにしたネットワークサービスを提供するものである。実のところ、決まっているのはその点と名前だけで、設計は何も決まっていない。ここにあーだこーだ書きながら詰めていこう。 背景 先に明言すべきは、これはKyoto CabinetをストレージにしたTokyo Tyrant相当の製品ではない。TTはキャッシュサーバではないので、memcachedで言う所のexpireをサポートしていない。しかし、Kyoto Tycoonはキャッシュサーバとしての利便性を追求し、もちろんexpireをサポートするとともに、レプリケーションなどの重量級の機能は割愛する。 なぜこれを作るかという理由は大きく二つ

  • Kazuho@Cybozu Labs: キャッシュの上手な使い方

    « C-0.05 | メイン | cygwin + mod_perl » 2006年02月08日 キャッシュの上手な使い方 キャッシュといっても、ウェブブラウザやウェブプロキシのキャッシュのことです。 ・Internet Explorer のキャッシュの動作 Internet Explorer は、同一ウィンドウ内で複数回同じウェブページを読み込む場合、2回目以降はキャッシュのデータを使用します (デフォルト設定の場合、 Last-Modified または Expires ヘッダがついている場合のみ)。 つまり、同じウィンドウの中で、 ページA を読み、次にページB を読み、そしてページA を再び読み込むようなケースでは、2回目にページ A を表示する際にはキャッシュのデータが使用され、ウェブサーバへの再問い合わせは行われません。 また、 Last-Modified ヘッダと Expire

  • ブラウザキャッシュによる HTTP 高速化チューニング

    かれこれ一年ほど前に実施した実サービスでの apache のチューニングネタを思い出したように書いています。 以前いた部署では少ないサーバ台数で大量のリクエストを如何に処理しきるかってことに燃えていたので、静的コンテンツなどをブラウザに支障のない範囲で最大限にキャッシュさせ、サーバとネットワークの負荷を最小化させていました。 当時参考にした情報源は以下の3つでした。 どのようなレスポンスヘッダを返しておけばブラウザキャッシュを最大化できるかのテクニックがまとめられています。 ブラウザキャッシュとレスポンスヘッダ - murankの日記 Kazuho@Cybozu Labs: キャッシュの上手な使い方 [Studying HTTP] HTTP Status Code チューニングにおいて重要なのは自分自身での検証。というわけで自前で検証した結果と検証するために用意したプログラムを公開します。

  • nginxを使った簡単快速reverse proxyサーバ構築法 - Masatomo Nakano Blog

    ここのブログは、nginx(proxyサーバ)が外からのアクセスを受け、それを thin + sinatra (アプリケーションサーバ) と mongoDB (データベースサーバ)で処理する、というWebシステム定番の三層構造で構成している。 ただ、見てわかるようにほぼ静的なコンテンツのサイトなので、アクセス毎にアプリケーションサーバを走らせる意味がない。また、このVPSの一番安いコースにおいているので、あまり贅沢に資源を使いたくない。と言ったことから生成したhtmlをキャッシュして2度目のアクセスからはアプリケーションサーバやデータベースにアクセスしないようにしている。 Webシステムによっては、アプリケーションサーバで静的なhtmlファイルを作成し負荷の軽減をしたりするが、キャッシュファイルを自前で扱うのはvalidation等色々だるいので、このブログシステムではnginxに任せてい

  • Sinatraのパフォーマンスアップ作戦 - GIOの日記

    自サービスを続々とSinatraってます。 その際、パフォーマンスアップを狙い、Memcached(+memcache-client)を利用した、Railsのフラグメントキャッシュライクに使えるExtensionを書きました。 使い方やコードはコチラにあります http://github.com/gioext/sinatra-memcache/tree/master 使い方 # start memcached cd myapp git clone git://github.com/gioext/sinatra-memcache.git lib/sinatra-memcache# app.rb require 'rubygems' require 'sinatra' require File.dirname(__FILE__) + '/lib/sinatra-memcache/lib/sin

    Sinatraのパフォーマンスアップ作戦 - GIOの日記
  • Return 0

    return0.infoに移転。昔の日記はまんま残してるので読みたい人はどうぞ。 世界樹の迷宮関係のコンテンツは移行が面倒なのでこっちに残すことにした。 世界樹の迷宮プレイ記録 世界樹の迷宮IIプレイ記録 世界樹の迷宮IIIプレイ記録

  • http://blog.as-is.net/2007/02/modcache.html

  • 小野マトペの業務日誌(アニメ制作してない篇) - Safari3のリロードは強制リロード

    この一週間、Webページのブラウザキャッシュについて少し調べてた。 Webコンテンツを出来るだけブラウザキャッシュさせて転送量を削減しようと目論んでいて、PHPアプリケーション側でIf-Modified-SinceヘッダとDB最終更新時間を照らし合わせて、更新がなければ304を返す、という一般的なブラウザキャッシュ利用実装を行ったんだけど、テストしてみたらSafariが全然キャッシュを使ってくれない。と言うわけでApacheのログを取って色々調べた結果、表題のことが分かった。 Safariのリロードは、いわゆる強制リロード相当である 一応簡単に説明すると、IEなどの一般的なブラウザはページの読み込みシチュエーションによって、ブラウザ内のキャッシュを使うかどうかのポリシーを変化させている。IEやFxでは、 通常ロード ブックマークやロケーションバーからページにアクセスした場合 リンクや「戻る

    小野マトペの業務日誌(アニメ制作してない篇) - Safari3のリロードは強制リロード
  • nginx+squidで画像キャッシュサーバーの作り方 - hideden.hatenablog.com

    仕事で画像キャッシュサーバーを構築した時のメモ。大規模事例の設定例が検索してもあまり見つからなかったので同じような境遇の誰かの参考になれば。 ピーク時のトラフィックは数Gbps 画像総容量は数十TB バックエンドのstorageが複数種類 規模とアクセス量とアクセスされる画像の種類が多いので、squidでdisk cacheを使用するとCOSS等を使用してもdiskIOで詰まる為、全てon memory cache。cache容量を確保する為に必然的にcacheサーバーの台数も数十台。 1. squidをsibling構成で並列に並べる cache_peer 10.0.1.1 sibling 80 3130 no-query no-digest proxy-only cache_peer 10.0.1.2 sibling 80 3130 no-query no-digest proxy-o

    nginx+squidで画像キャッシュサーバーの作り方 - hideden.hatenablog.com
  • DBIx::Skinnyを使った際のCache方法考察 - Hatena::Diary::Neko::kak 500 Internal Server Error

    DBIx::SkinnyにはDODやData::Modelのようにキャッシュを透過的に扱う 便利機能はありません。 無いのでラッパーを書きませう。 毎度の事でデモは http://github.com/nekokak/p5-dbix-skinny-sample/tree/master/cache/ に置いてあります。 ユーザテーブルがあるとします。 CREATE TABLE user ( id INTEGER PRIMARY KEY AUTOINCREMENT, name VARCHAR(255) NOT NULL, UNIQUE(name) ); ユーザの情報をキャッシュからひけなければDBから引っ張って キャッシュしておき、次に使う時はキャッシュデータを使うという典型的なパターンです。 userテーブルの定義などはこのようにします。 今回はinflate/deflateも一緒にやってみ

    DBIx::Skinnyを使った際のCache方法考察 - Hatena::Diary::Neko::kak 500 Internal Server Error
  • 2次キャッシュを意識してコーディングしてる?

    先日、北陸twitterオフで、2次元配列をx,yの順でアクセスするのと、y,xの順でアクセスするのでは、実行速度が違うんだよ、という話をしていたのだが、正直このネタは4、5年前にMIPSを使っていたときの事なので、今でも有効なのか?と思いベンチマークプログラムを作成して検証してみた。 内容 Integer型二次元配列の内容を処理する時に、アドレス順に行う(キャッシュにヒットしやすい)場合と、そうでない(キャッシュにヒットしにくい)場合を比較してみた。 環境 MacBookPro (Core2Duo 2.4G / Memory 4GB) MacOS X 10.5.6 gcc 4.0.1(-O2で最適化) 結果 X Y キャッシュヒット キャッシュミス diff 1024 1024 0.002351 sec 0.062166 sec x 26.44 1024 2048 0.004840 se

  • mod_libmemcached_cacheでApacheのcacheをmemcachedに保存する : blog.nomadscafe.jp

    mod_libmemcached_cacheでApacheのcacheをmemcachedに保存する Apacheのmod_cacheのキャッシュ保存先にmemcachedが使えればいいのにと長年思ってきましたが、mod_libmemcached_cacheがそれを実現してくれました。 しかも、libmemcachedを利用しているので、性能も高く、またConsitent Hashingも使えますし、バイナリプロトコルもばっちりです。 図にするとこんな感じ。revserse proxyのcacheがmemcachedになるので、cache効率が上がり、またApplicationサーバからも同じmemcachedが参照できるのでcacheを変更したりできるかもしれません。 導入 mod_libmemcached_cacheはgithubから入手できます http://github.com/a

  • naoyaのはてなダイアリー - Linuxのページキャッシュ

    世間では PHP が、Perl が、と盛り上がっているようですが空気を読まずまたカーネルの話です。今回はページキャッシュについて。 /dev/shm に参照系DBを持っていくと I/O 負荷が激減した件(当たり前だけど) - drk7jp で、ディスク上にあったファイルを /dev/shm (tmpfs) に移したら I/O 待ちがなくなって負荷がさがった、ということなんですがおそらくこれは tmpfs に置く必要はないかなと思います。Linux (に限らず他の OS もそうですが) にはディスクの内容を一度読んだらそれはカーネルがキャッシュして、二度目以降はメモリから読む機構 = ページキャッシュがあります。tmpfs にデータを載せることができた、ということは物理メモリの容量に収まるだけのデータサイズかと思うので、放っておけば該当のファイルの内容すべてがメモリ上にキャッシュされて io

    naoyaのはてなダイアリー - Linuxのページキャッシュ
  • Ehcache

    Ehcache is an open source, standards-based cache that boosts performance, offloads your database, and simplifies scalability. It's the most widely-used Java-based cache because it's robust, proven, full-featured, and integrates with other popular libraries and frameworks. Ehcache scales from in-process caching, all the way to mixed in-process/out-of-process deployments with terabyte-sized caches.

  • キャッシュしよう

    京都観光で散財しすぎて貯金がないmalaです。こんにちは。キャッシュの話を書きます。 色んなキャッシュがあります データベースから引く前にmemcachedから取得したり テンプレートエンジンのレンダリング結果をキャッシュしたり 各種ウェブサービスのリクエスト結果をキャッシュしたり その他諸々CPUったり時間のかかる処理をキャッシュしたり 簡単に思いつくのはこの程度ですが、スケーラブルなウェブサイトを構築するには常識的に考えてそんなのキャッシュしねーだろうというようなものをキャッシュする必要があります。 DateTimeをキャッシュしよう 同じ時刻に対するDateTimeオブジェクトをキャッシュします。 package MyDateTime; use strict; use base qw(DateTime); my %CACHE; sub now { my $class = shif

  • もう少しだけmod_cacheを深追いしてみる - Ogawa::Memoranda

    Posted by: Hirotaka Ogawa @ February 16, 2007 05:42 PM | 前のエントリーで書いた方法だとブラウザによってはページをリロードするたびに待たされることになります。 mt-search.cgiをmod_cacheで超高速化する!! - Ogawa::Memoranda なんでかな?と思ったので、動的コンテンツ(この場合はURLにクエリ文字列を含む動的コンテンツ)へのリクエストに対する、(mod_cacheで実現された)サーバーサイドキャッシュの振る舞いをもう少し深追いしてみました。 サーバーサイドキャッシュがない場合 サーバーサイドキャッシュがない場合には、すべての動的コンテンツへのリクエストごとにレンダリングを行い、そのデータがレスポンスとして返されます。 動的コンテンツで、Last-Modified, ETagヘッダを含むレスポンスを行

  • 1