Redis の SortedSets 同点問題について - blog.nekokak.org
WEB+DBのRedis特集をひろせまさあきさんと共同で執筆しました。 WEB+DB PRESS Vol.73posted with amazlet at 13.03.05設樂 洋爾 白土 慧 奥野 幹也 佐藤 鉄平 後藤 秀宣 mala 中島 聡 堤 智代 森田 創 A-Listers はまちや2 大和田 純 松田 明 後藤 大輔 ひろせ まさあき 小林 篤 近藤 宇智朗 まかまか般若波羅蜜 Mr. O 技術評論社 売り上げランキング: 335 Amazon.co.jpで詳細を見る 買ってください。 このRedis特集の第五章では、Redisを使ったリアルタイムランキングについて取り上げたのですが、 記事中にある同点問題について、執筆時から状況が変わりましたのでupdateします。 記事中では、RedisのSortedSetsはスキップリストというアルゴリズムを使っている特性上、 同じス
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
Tengについて
先ほどTengという新しいORMをリリースしました。 TengはDBIx::Skinnyの後継バージョンと捉えていただいて結構です。 DBIx::Skinnyはおおよそ３年前ほどに一人でつくりはじめたORMで 現在に到るまでに様々な仕様変更を繰り返し、 結構秘伝のタレ的なコードが目立つようになってきました。 元々はDBIx::Skinnyをリファクタリングすることで済まそうと思っていたのですが、 後方互換を残したままのリファクタリングに限界を感じました。 多くの人に使っていただいている現状で後方互換を簡単に捨ててしまうのは 宜しく無いとの判断から別プロジェクトとしてリリースするに至りました。 DBIx::Skinnyは現状、バクレポートも特別なく 問題なく継続してご利用頂けると思いますので、ご安心ください。 また、なにか大きな問題点があれば、サポートしますのでpatches&testsウエ
DBIx::Skinnyのなおしたいところ(案)
・DBIx::Skinny::SQLがいけてないのでなおしたい $skinnyのObjectに依存しているのがretrieveメソッドだけなので 若干のインコンパチな変更になるけどなんとかしたいかな。 あとDBIx::Skinny::Accessorを廃止したい。 正直SQL builderとしていけてない。（Data::ObjectDriverからぱくっといてなんだけど） complex_whereとか書きにくすぎる ・AnonRowクラスの廃止 Rowクラス生成を必須とするかどうか。 ・ClassメソッドでDBIx::Skinnyを操作出来るインタフェース 正直インスタンスをつくって操作したほうがよいのでSkinnyとして廃止したい。 後方互換かんがえると結構大変なことなり。 ちなむとヤルにしてもいきなりエラーになるとかはしないのでご安心を。 そしてヤルか
「バリデーションはどの位置で必要か」のやりとりで思ったこと。
個人的にはapi単位での引数のバリデーションはあった方がbetterかなとおもう。 tokuhiromが 複数人で開発している場合では、クラスをかいた人と利用者がちがう場合があるので、validation は必要だとおもうけれど。と書いてるけどこれはまさにその通りで、 さらに言うと自分の書いたコードも時間が経てば他人が書いたコードと一緒だから バリデーションの情報から引数の情報を読み取れると、 そのapiに対する理解の速度は向上するとおもう。 実行速度とのトレードオフだったりはするだろうけど、無駄な引数渡したり、本当は必要な引数を渡しきれなかったりして それで誤動作とかするくらいならバリデーションあったほうがいいんじゃないでしょうかね。 perlcodesampleさんの 動的言語の利点は、引数にどのような型でも渡せるので、静的言語のように型の指定がいらないということです。つまり、動的言語
メモリ使用量の確認
サーバのメモリが思った以上に消費していたのでサックリ調べてたのですが 各プロセスのメモリ使用状況の調べ方としては ps aux --sort=-rss | head -40とやるとRSSのサイズでソートしてくれるのでheadとかでみてやればメモリ使用量が多い順に参照可能。 ただたんにps auxしただけだと見るのがしんどい。 topでもshift+Mで同じ感じでみれるのでそれでも良い。 （cを入力してプロセスの詳細を表示するとなおよい） あとはCoWに乗ってるかを調べたが、 http://d.hatena.ne.jp/naoya/20080212/1202830671 naoyaさんが紹介されている方法そのまんまでよいでしょう。 sudoして実行すること。 Cowはアプリの質にもよるが基本的にはライブラリが共有メモリに乗ってればいいから アプリの質をみつつsharedなパーセントを調整出
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
株式会社ディー・エヌ・エーに入社しました
退職のお知らせ