なんだ、やっぱりファイルキャッシュ使った方が速いんじゃん。良かった。デメタシ、デメタシ。
…というお話。
前のエントリで Benchmark 取った時は、LWP でページをゲットしてました。しかし、良く考えたらそこにはネットワークが横たわっていて、純粋にプログラムの速度を計測できていないじゃん、と気付いた。
そこで再度計測しようと、system 関数使って直接 cgi を叩いてみた、5回の結果が以下。
00.3.0cache: 51 wallclock secs ( 0.00 usr 0.06 sys + 33.41 cusr 3.95 csys = 37.42 CPU) @ 1600.00/s (n=100)
01.3.0nocache: 67 wallclock secs ( 0.03 usr 0.04 sys + 39.67 cusr 3.84 csys = 43.59 CPU) @ 1422.22/s (n=100)
02.2.2b1: 71 wallclock secs ( 0.01 usr 0.06 sys + 36.45 cusr 3.91 csys = 40.43 CPU) @ 1422.22/s (n=100)
00.3.0cache: 64 wallclock secs ( 0.01 usr 0.06 sys + 33.85 cusr 3.77 csys = 37.69 CPU) @ 1422.22/s (n=100)
01.3.0nocache: 84 wallclock secs ( 0.00 usr 0.07 sys + 39.38 cusr 4.39 csys = 43.84 CPU) @ 1422.22/s (n=100)
02.2.2b1: 68 wallclock secs ( 0.00 usr 0.07 sys + 36.76 cusr 3.82 csys = 40.65 CPU) @ 1422.22/s (n=100)
00.3.0cache: 49 wallclock secs ( 0.00 usr 0.07 sys + 33.51 cusr 3.82 csys = 37.40 CPU) @ 1422.22/s (n=100)
01.3.0nocache: 62 wallclock secs ( 0.02 usr 0.05 sys + 39.48 cusr 3.94 csys = 43.48 CPU) @ 1600.00/s (n=100)
02.2.2b1: 58 wallclock secs ( 0.00 usr 0.06 sys + 36.99 cusr 3.35 csys = 40.41 CPU) @ 1600.00/s (n=100)
00.3.0cache: 47 wallclock secs ( 0.00 usr 0.07 sys + 33.65 cusr 3.57 csys = 37.29 CPU) @ 1422.22/s (n=100)
01.3.0nocache: 61 wallclock secs ( 0.01 usr 0.07 sys + 39.52 cusr 3.94 csys = 43.53 CPU) @ 1280.00/s (n=100)
02.2.2b1: 65 wallclock secs ( 0.00 usr 0.07 sys + 36.76 cusr 3.47 csys = 40.30 CPU) @ 1422.22/s (n=100)
00.3.0cache: 53 wallclock secs ( 0.01 usr 0.05 sys + 33.80 cusr 3.54 csys = 37.40 CPU) @ 1600.00/s (n=100)
01.3.0nocache: 68 wallclock secs ( 0.00 usr 0.08 sys + 39.62 cusr 3.93 csys = 43.63 CPU) @ 1280.00/s (n=100)
02.2.2b1: 59 wallclock secs ( 0.00 usr 0.07 sys + 36.52 cusr 3.75 csys = 40.34 CPU) @ 1422.22/s (n=100)
いずれも 2.2b1 より 3.0(a1) の方が速かった。微々たる差ではあるけれど。計測対象はトップページなので、ページ分割が発生するような場合にはもう少し差が出るかもしれない。
というわけで、とりあえず「前バージョンより遅くなったやないか！」的な最悪の事態は免れられる模様。特に App サーバより極端に DB サーバが重たく、足を引っ張られているような場合には有効でしょう（上記はさくらインターネットのプレミアム、DB サクサクの環境で計測しています）。
コメント