前回の記事、tugela cache検証(メモリ使用量制御)で作成した連続set/getスクリプトを
走らせていると、ときおり連続して(数秒程度)set/getに失敗していた。
起動オプションの
-s <num> sync this often seconds
を短くしたり、大量にset/get(テストでは1000万件set/getしてみた)を繰り返すと
頻発するので、おそらくメモリ上のデータをディスク上へsyncする際にDB全体が
ロックされてその間はset/getともに失敗するのではないかと思われ。
メモリ上のデータがでディスク上へ書き込まれるタイミングとしてはおそらく
かな。
データの書き込みに失敗しても再度繰り返せばいいわけだから
まあこのへんはご愛嬌ということで。
(読み込みについては微妙ですが、まあ大勢に影響がなければよいのではないかと)
で、パフォーマンスですが。
データが空の状態で100万件のレコード(1レコード160バイト程度のデータ)をset/getするのにかかった時間は85秒。
1万件につき0.85秒。
同じ条件でmemcachedとMySQLでも実施してみたところ、かかった時間は以下のとおり。
マシンや差し込むデータ、設定ファイルのチューニングによって変わってくると思うのであくまで参考まで。
当然memcachedほどのパフォーマンスはでないが使ってみる価値はありそう。
走らせていると、ときおり連続して(数秒程度)set/getに失敗していた。
起動オプションの
-s <num> sync this often seconds
を短くしたり、大量にset/get(テストでは1000万件set/getしてみた)を繰り返すと
頻発するので、おそらくメモリ上のデータをディスク上へsyncする際にDB全体が
ロックされてその間はset/getともに失敗するのではないかと思われ。
メモリ上のデータがでディスク上へ書き込まれるタイミングとしてはおそらく
- 起動オプション("-s")で指定したタイミング間隔
- expireしていないデータの総サイズが使用許可メモリ量を超えた時
かな。
データの書き込みに失敗しても再度繰り返せばいいわけだから
まあこのへんはご愛嬌ということで。
(読み込みについては微妙ですが、まあ大勢に影響がなければよいのではないかと)
で、パフォーマンスですが。
データが空の状態で100万件のレコード(1レコード160バイト程度のデータ)をset/getするのにかかった時間は85秒。
1万件につき0.85秒。
同じ条件でmemcachedとMySQLでも実施してみたところ、かかった時間は以下のとおり。
デーモン名 | 実行時間(100万件set/get) | 率(memcachedを100%として) |
---|---|---|
tugela | 85秒 | 144% |
memcached | 59秒 | - |
mysqld | 129秒 | 219% |
マシンや差し込むデータ、設定ファイルのチューニングによって変わってくると思うのであくまで参考まで。
当然memcachedほどのパフォーマンスはでないが使ってみる価値はありそう。