どこかで「mgetはgetより数十倍高速」という話を聞いたような気がしたので、件数を増やしながらテストしてみたよ。


条件

  • Cent OS 5(1台)
  • memcached 1.2.6
  • PHPプログラム上でPecl::Memcachedを使用(mgetはgetMulti()に相当)



計測方法

それぞれ5回ずつ計測し、平均値を算出。

テスト結果

要素数getmgetget/mget
10.00004730.0001240.379
100.0005070.0001543.283
1000.004300.00042410.143
1,0000.04410.04261.036
2,0000.07540.03732.021
5,0000.2270.03686.184
10,0000.4330.04369.929
20,0000.9640.073713.084
50,0002.3200.191812.094


正直な話、一気に50,000要素を抽出するテストに何の意味があるのだという感じではあります。実際にはいくら何でも、100件くらいまでで済むと思いますが…資料ということで。


資料を見る限りで面白そうな所を抽出すると。


1件だけならgetの方が早い

まぁ余分なことをしてないからということでしょうね。テストプログラム側を変えて揃えても結果は変わりませんでした。


100件取得時のmgetのパフォーマンスが異常に良い

格納データの問題もあるかも知れません。
追試として20件刻みで100件まで取得して並べてみます。

要素数getmgetget/mget
200.0009120.0001555.893
400.002490.00017314.335
600.002920.00025411.495
800.005610.00039814.087

大体、30件くらいから急激にパフォーマンスが上がっているようです。
ただし要素数が少ないと時間の振れ幅が大きい(40件でも8-20倍くらいまでの振れ幅がある)ので、データ自体の信頼度としてはいまいちです。


1,000件取得時のmgetのパフォーマンスが悪い

こちらも一応追試として100件刻みで1,000件まで取得して並べてみました。

要素数getmgetget/mget
2000.01180.00099111.929
3000.01620.0014511.123
4000.02050.0016512.432
5000.02570.03410.756
6000.03000.03500.857
7000.03470.03421.015
8000.04160.03461.204
9000.03930.03501.124

要素数500でmgetのパフォーマンスが急に落ちてます。データのサイズの問題でしょうか…何度か試行してみましたが余り変わりませんでした。

もしデータサイズの問題だとすると、この環境ではおおよそ似たようなサイズのデータをが大量に格納しているので、Chunckをチューニングすればもっと良いパフォーマンスが出せるかも知れません。
ただ、現実の場面では500リクエストをmgetで同時に送ることはないのですね…もっと大きなデータサイズなら、もっと小さな要素数で影響が出るのかも知れませんが。



結論みたいなもの

本当は「ああ!やっぱりmget最高!!!」と書けるデータが出るのを期待していたんですが、あまりカタルシスのある結果は出ませんでした。

ただ全体をならして考えるとgetは要素数に比例して増えている印象があるのに対してmgetの方はどちらかというと対数関数的ですね。現実的な数の要素(100件くらいまで)取得を考えると、5-10倍程度のパフォーマンス改善が見込めそうです。

また機会があれば、サイズの違う他のデータでテストしてみたいと思います。