シンデレラと七人の小人達の食卓II
こちら，店の看板等に「シンデレラ」の字は入ってないので，いつもちょっと道を迷います．
ぐるなび - レストラン予約と宴会・グルメ情報 検索サイト
とりあえずは，「7人の小人達の小さなスプーンタルトに乗せた1口オードブル盛り合わせ」なんですが結構ボリュームがあって，テーブルの端から端まで，お皿が占めてます．狭いテーブルでこれ頼んだら，たぶんはみ出す．
「パンチェッタとポルチーニ黒トリュフを散りばめたカルボナーラスパゲティ」要するにただのカルボナーラやった．．．味は美味しかったですけどね．
こちらのカクテルは，「魔女の毒りんご」
こちらの1対のカクテルは，「お姫様と王子様に捧げる愛しの薔薇」（なんちゅーネーミング．．．）
こちらは頼んであった誕生日ケーキ．左側の塊がシンデレラのようです．ショートケーキが2個置いてあって，その他皿の上には小さなロールケーキも置いてあります．
最速KVS研究第4弾
いつまで続くか分からないシリーズ．
最速KVS研究第一弾（memcached/Tokyo Tyrant/Kyoto Tycoon） - なぜか数学者にはワイン好きが多い
KVS最速テスト第二弾（memcached V.S. Redis） - なぜか数学者にはワイン好きが多い
最速KVS研究第3弾（memcached V.S. redis 第2弾） - なぜか数学者にはワイン好きが多い
第3回で，以下のブログとは異なる結論が出てしまいました．
Redis vs Memcached | /sys/toilet
こちらのテストはどうやってもmemcachedが最速なのですが，上記のブログによるとRedisの方が速いとのこと．
テストのやり方の違いとして，Redisへのアクセス方法が違ったのでそれは検証したのですが，
最速KVS研究第3弾（memcached V.S. redis 第2弾） - なぜか数学者にはワイン好きが多い
Credisの方が2倍ほど遅い．．．
Credisクライアントを使うよりもPocoを使う方が速かったです．
そこで次の違いとして，こちらではKeyやValueの長さを全て固定して同時アクセス数を変化させてテストしているので，上記ブログのように値の長さを変化させたテストをしてみようと思います．
実際に使うことを考えると，Keyの長さがそうやたらに変化することは考えられません．私のテストでもハッシュ関数を通して長さを統一してしまっています．
ただ，Valueが追加されていって長くなるケースはありそうです．
というわけで，memcached, Tokyo Cabinet+Tokyo Tyrant, Kyoto Cabinet+Kyoto Tycoon, Redisで，Valueの長さを変化させて速度を測ってみます．
Key長は32バイト固定，Value長を32バイト，320バイト，3200バイトと可変させてget/setの速度を検証してみました．
set/get（書き込み・読み込み）ではそれほど各KVSで差が出なかったので，スレッド数を変化させた場合のグラフだけ載せます．
Value長を変えてもmemcachedが最速でした．というか，Value長が3kバイトを超えると，Redisは急激に遅くなりました．
何が遅くなったかというと，getもsetも両方遅くなったので．．．
