条件
- Cent OS 5（1台）
- memcached 1.2.6
- PHPプログラム上でPecl::Memcachedを使用（mgetはgetMulti()に相当）
計測方法
それぞれ5回ずつ計測し、平均値を算出。テスト結果
| 要素数 | get | mget | get/mget |
|---|---|---|---|
| 1 | 0.0000473 | 0.000124 | 0.379 |
| 10 | 0.000507 | 0.000154 | 3.283 |
| 100 | 0.00430 | 0.000424 | 10.143 |
| 1,000 | 0.0441 | 0.0426 | 1.036 |
| 2,000 | 0.0754 | 0.0373 | 2.021 |
| 5,000 | 0.227 | 0.0368 | 6.184 |
| 10,000 | 0.433 | 0.0436 | 9.929 |
| 20,000 | 0.964 | 0.0737 | 13.084 |
| 50,000 | 2.320 | 0.1918 | 12.094 |
正直な話、一気に50,000要素を抽出するテストに何の意味があるのだという感じではあります。実際にはいくら何でも、100件くらいまでで済むと思いますが…資料ということで。
資料を見る限りで面白そうな所を抽出すると。
1件だけならgetの方が早い
まぁ余分なことをしてないからということでしょうね。テストプログラム側を変えて揃えても結果は変わりませんでした。100件取得時のmgetのパフォーマンスが異常に良い
格納データの問題もあるかも知れません。追試として20件刻みで100件まで取得して並べてみます。
| 要素数 | get | mget | get/mget |
|---|---|---|---|
| 20 | 0.000912 | 0.000155 | 5.893 |
| 40 | 0.00249 | 0.000173 | 14.335 |
| 60 | 0.00292 | 0.000254 | 11.495 |
| 80 | 0.00561 | 0.000398 | 14.087 |
大体、30件くらいから急激にパフォーマンスが上がっているようです。
ただし要素数が少ないと時間の振れ幅が大きい（40件でも8-20倍くらいまでの振れ幅がある）ので、データ自体の信頼度としてはいまいちです。
1,000件取得時のmgetのパフォーマンスが悪い
こちらも一応追試として100件刻みで1,000件まで取得して並べてみました。| 要素数 | get | mget | get/mget |
|---|---|---|---|
| 200 | 0.0118 | 0.000991 | 11.929 |
| 300 | 0.0162 | 0.00145 | 11.123 |
| 400 | 0.0205 | 0.00165 | 12.432 |
| 500 | 0.0257 | 0.0341 | 0.756 |
| 600 | 0.0300 | 0.0350 | 0.857 |
| 700 | 0.0347 | 0.0342 | 1.015 |
| 800 | 0.0416 | 0.0346 | 1.204 |
| 900 | 0.0393 | 0.0350 | 1.124 |
要素数500でmgetのパフォーマンスが急に落ちてます。データのサイズの問題でしょうか…何度か試行してみましたが余り変わりませんでした。
もしデータサイズの問題だとすると、この環境ではおおよそ似たようなサイズのデータをが大量に格納しているので、Chunckをチューニングすればもっと良いパフォーマンスが出せるかも知れません。
ただ、現実の場面では500リクエストをmgetで同時に送ることはないのですね…もっと大きなデータサイズなら、もっと小さな要素数で影響が出るのかも知れませんが。
結論みたいなもの
本当は「ああ！やっぱりmget最高！！！」と書けるデータが出るのを期待していたんですが、あまりカタルシスのある結果は出ませんでした。ただ全体をならして考えるとgetは要素数に比例して増えている印象があるのに対してmgetの方はどちらかというと対数関数的ですね。現実的な数の要素（100件くらいまで）取得を考えると、5-10倍程度のパフォーマンス改善が見込めそうです。
また機会があれば、サイズの違う他のデータでテストしてみたいと思います。
