Jitsi Meet is a secure videoconference service that allows you to host your conference on your se...
Tutorials
Jitsi Meet is a secure videoconference service that allows you to host your conference on your se...
にひりずむ::しんぷる - shipped Cache::LRU::WithExpires
Cache::LRU::WithExpires - can set an expiration for the Cache::LRU - metacpan.org Cache::LRU に expires の機能をつけただけのモジュールですね。 最初はプロダクトのコードで使っていましたが、だれか (たしかグニャラくん？) がコピペして再利用していたという話を聞いて、まぁ需要あるなら出すかーって感じで考えててすっかり忘れてたんですが思い出したので出しましたっていうストーリーです。 使い方は簡単で、オケツに expires を指定するだけです。Time::HiRes しているので、ミリ秒も OK。 use Cache::LRU::WithExpires; my $cache = Cache::LRU::WithExpires->new; $cache->set('hirose', '31',
ナイーブなオンメモリキャッシュ実装をかいた - tokuhirom's blog
https://github.com/tokuhirom/Cache-Memory-Simple/blob/master/lib/Cache/Memory/Simple.pm Expire されたデータがとれなくなるだけのナイーブなキャッシュ実装をかきました。 わりとみんな手でかいてるとおもうんですが、手でかくとバグりやすいしテストかくのも面倒なので CPAN にあげておくといういつものアレです。Expire がきいてシンプルではやそうなのがなかったんでまあ。 10秒ぐらいhttpdの中にオンメモリキャッシュしときたいなあ、という時などにどうぞ。 使い方は以下のようなかんじです。 use Cache::Memory::Simple; use feature qw/state/; sub get_stuff { my ($class, $key) = @_; state $cache = C
KeyedMutex::Memcached ってモジュールをリリースして何も言ってなかった件 - 日向夏特殊応援部隊
id:kazuhooku さんがかつて作った KeyedMutex を memcached でやってしまおうと言うのがこのモジュールの目的です。 KeyedMutex の場合は、keyedmutexd と言うそれ専用の daemon を立ち上げなければいけませんが、このモジュールの場合は既存のシステムに memcached があれば普通に使えます。 trial を 0 にすると timeout で lock が expire するか、誰かが lock を開放するまで延々と lock の獲得が出来るまでビジーループします。一方で trial を有限の正整数とすると、その試行回数で lock が獲得出来ない場合は即座に諦めます。 正規の使い方としては lock を獲得出来るのが同時に1クライアントのみで他はそれが開放されるまで待たせると言うのが正解ですが、ちょっと変わった使い方としては、例えば
Cache::Memcached::Fastの高速化
一番簡単に高速化するには シリアライザをData::MesagePackにするとよいかもしれない。 #! /usr/bin/perl use strict; use warnings; use Cache::Memcached::Fast; use Data::MessagePack; use Benchmark qw/timethese/; my $normal = Cache::Memcached::Fast->new({ servers => ['127.0.0.1:11211'], serialize_methods => [ \&Storable::freeze, \&Storable::thaw ], }); my $msgpack = Cache::Memcached::Fast->new({ servers => ['127.0.0.1:11211'], serialize
キャッシュシステムの Thundering Herd 問題対策モジュール Cache::Isolatorというのを書いた。 - blog.nomadscafe.jp
やや大袈裟な名前ですが「memcachedにおけるキャッシュシステムの Thundering Herd 問題への対策案」とか「キャッシュシステムの Thundering Herd 問題への対策案。その2 排他制御」で書いていたコードをモジュールにした github: https://github.com/kazeburo/Cache-Isolator 機能としては、平行動作数を制御できるget_or_setと、一定の確率で少し早く有効期限が切れるキャッシュの保存、取得、削除あたりがあげられます 使い方ですが、まず、get_or_setの例。 my $isolator = Cache::Isolator->new( cache => Cache::Memcached::Fast->new(...), concurrency => 4, # get_or_setのcallbackの最大平行動作
memcachedにおけるキャッシュシステムの Thundering Herd 問題への対策案 - blog.nomadscafe.jp
キャッシュシステムの Thundering Herd 問題とは、 通常、キャッシュに格納されるデータは、それぞれ単一の生存時間をもっています。問題は、頻繁にアクセスされるキャッシュデータがエクスパイアした際に発生します。データがエクスパイヤした瞬間から、並行に走る複数のアプリケーションロジックがミスヒットを検知し、いずれかのプロセスがキャッシュデータを格納するまでの間、同一のリクエストが多数、バックエンドに飛んでしまうのです。 という問題。クエリが重かったりするとそれだけでシステムに致命的な負荷を与えてしまい、キャッシュがあるにも関わらずキャッシュが切れたタイミング全体が停止することも考えられます。memcachedでこの問題に対応するため、次のような手段を考えてみました。 まず、保存時に通常のキャッシュと、それよりも指定した秒数Expiresが短いキャッシュを2つmemcachedに対し
Cache::LRU (a handy and fast in-memory cache module in pure-perl)
Cache::LRU (a handy and fast in-memory cache module in pure-perl) Last week, after not being able to find a handy and fast cache module, I decided to write one by myself, and the outcome is Cache::LRU. Cache::LRU is an in-memory cache module written in pure-perl. It has no dependencies, and the code is less than 100 lines long. Yet it is faster than other modules as the result of a primitive bench
ブラウザキャッシュによる HTTP 高速化チューニング
かれこれ一年ほど前に実施した実サービスでの apache のチューニングネタを思い出したように書いています。 以前いた部署では少ないサーバ台数で大量のリクエストを如何に処理しきるかってことに燃えていたので、静的コンテンツなどをブラウザに支障のない範囲で最大限にキャッシュさせ、サーバとネットワークの負荷を最小化させていました。 当時参考にした情報源は以下の３つでした。 どのようなレスポンスヘッダを返しておけばブラウザキャッシュを最大化できるかのテクニックがまとめられています。 ブラウザキャッシュとレスポンスヘッダ - murankの日記 Kazuho@Cybozu Labs: キャッシュの上手な使い方 [Studying HTTP] HTTP Status Code チューニングにおいて重要なのは自分自身での検証。というわけで自前で検証した結果と検証するために用意したプログラムを公開します。
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も一緒にやってみ
Squidのキャッシュの消し方 : blog.nomadscafe.jp
Squidのキャッシュの消し方 Net::Squid::Purgeというモジュールがでてたので。 Squidのcacheの消し方は、Squidから特定のキャッシュのみを削除する方法にsquidclientを使ったやりかたが紹介されているのですが、上のモジュールはそれをPerlから便利に使えるようにしたもの見たいですね。 主にReverse Proxyとして使っているパターンですが、最近ではsquidclient使ったり、IO::Socketやtelnetで叩くのが面倒なので、HTTPの仕様を利用しています。 HTTP/1.1の仕様でキャッシュサーバは Cache-Control: max-age=n のようなリクエストを受け付けた場合に、キャッシュの経過時間がn秒よりも古かった場合、expires等が切れてなくても、オリジンのサーバにリクエストを行うことになっています。 そこでこれを利用し
キャッシュしよう
京都観光で散財しすぎて貯金がないmalaです。こんにちは。キャッシュの話を書きます。 色んなキャッシュがあります データベースから引く前にmemcachedから取得したり テンプレートエンジンのレンダリング結果をキャッシュしたり 各種ウェブサービスのリクエスト結果をキャッシュしたり その他諸々CPUを食ったり時間のかかる処理をキャッシュしたり 簡単に思いつくのはこの程度ですが、スケーラブルなウェブサイトを構築するには常識的に考えてそんなのキャッシュしねーだろうというようなものをキャッシュする必要があります。 DateTimeをキャッシュしよう 同じ時刻に対するDateTimeオブジェクトをキャッシュします。 package MyDateTime; use strict; use base qw(DateTime); my %CACHE; sub now { my $class = shif
Kazuho@Cybozu Labs: 負荷に応じてキャッシュを自動調節する Perl モジュール
« Re: PoCo::Client::HTTP が勝手に文字コードを変えてしまう件 | メイン | Cache::Adaptive の使い方 » 2007年05月09日 負荷に応じてキャッシュを自動調節する Perl モジュール Cache::Adaptive の使い方に続く 最近かりかりとサーバサイドの実装をしています。修行の成果、だいぶ複雑な SQL も書けるようになってきました。DBMS の気持ちを考えながら SQL 最適化するのは楽しいですね。しかし、いくら SQL を工夫したところでパフォーマンスの限界はあるわけです。 となると、採りうる選択肢はスケールアウト・スケールアップ・キャッシングの３つになります (もちろん組み合わせも可)。ただ、需要予測の最大値に基づいて機材を確保するのもあまり効率的とは言えませんし、リリース直後に徹夜でパフォーマンスのチューニングをするのもイヤです
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Cache-Memcached-Managed-0.26 - provide API for managing cached information - metacpan.org
re_その辺の空気とか