kusanagi.tokyo に挑戦してみる

KUSANAGI for さくらのクラウド つかってますか?

この記事は、さくらインターネット Advent Calendar 2016 その1の10日目の記事です。
こんにちは!KUSANAGIを作っている人、宮崎です。
みなさん、KUSANAGI for さくらのクラウド、もしくは、KUSANAGI for さくらのVPS 使ってますか?
KUSANAGIは、超高速WordPresss仮想マシンで、さくらのクラウドおよびさくらのVPSの仮想マシンイメージとして提供しています。

早いKUSANAGI(ただしkusanagi.tokyo)

KUSANAGI がどのくらい早いかというと、KUSANAGIのサイト(https://kusanagi.tokyo/)を見ていただければわかると思います。表示すると、右上にこんな数字が表示されます。


この数字は、WordPressでPHPでのページ生成をどのくらいの秒数で行ったのかを表示したものです。
ご覧のように 0.006、つまり 6ms でページを生成しています。
ただし、この kusanagi.tokyo は弊社のオンプレミス環境にて提供していて、4GHzクラスのCPUとPCIe接続のSSDを積んだ強力なマシンです。KUSANAGIのうたい文句で、「WordPressの実行時間3ミリ秒台、秒間1000リクエストをページキャッシュ非使用で実現」と書いてますが、これは、このkusanagi.tokyo で叩き出したものです。

さくらのクラウドで kusanagi.tokyo に挑戦

では、さくらのクラウドはこの性能は出ないのか?実際にやってみました。

4core 4GBメモリ

まずは、kusanagi.tokyo と同じ、4CPU4GBメモリのKUSANAGIを用意しました。なお、さくらのクラウドでは、WordPress構築スクリプトが提供されています。これを使うと起動するだけでKUSANAGI for さくらのクラウドがでWordPress構築済みの環境が要されます。超便利ですね。ちなみに、HHVMとNGINXで動作しています。
さて、SSH接続して、CPUとメモリ量を見てみると、以下の通り。

kusanagi@kusanagi ~]$ cat /proc/cpuinfo |tail -27

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 63
model name      : Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz
stepping        : 2
microcode       : 0x1
cpu MHz         : 2294.702
cache size      : 4096 KB
physical id     : 3
siblings        : 1
core id         : 0
cpu cores       : 1
apicid          : 3
initial apicid  : 3
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb lm c
onstant_tsc arch_perfmon nopl eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f1
6c rdrand hypervisor lahf_lm abm fsgsbase bmi1 avx2 smep bmi2 invpcid xsaveopt
bogomips        : 4589.40
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

[kusanagi@kusanagi ~]$ free -h
              total        used        free      shared  buff/cache   available
Mem:           3.9G        793M        2.1G        8.5M        1.0G        2.9G
Swap:          4.0G          0B        4.0G

メモリには余裕がありますね。
まずは、処理速度。kusanagi.tokyo と比べるため、一度WordPress の管理画面にログインした状態でトップページを表示します。
するとkusanagi.tokyoと同じ速度表示画面が右上に表示されます。なお、HHVMの真の性能を引き出すため、何度かリロードしたあとの表示です。

27msと4~5倍程度かかってます。まだ遅いですね。
ここで、ab テストを実施して同時接続数を測定します。同時500接続くらいで試しますが、KUSANAGI以外だとWebサーバが落ちたり、リクエスト失敗数が増えることがあるので注意してください。
また、このabテストは何度か同じコマンドを実行後の数値になります。

[kusanagi@kusanagi ~]$ ab -n 5000 -c 500 http://XXX.XXX.XXX.XX/ 2> /dev/null | grep -i requests
Complete requests:      5000
Failed requests:        0
Requests per second:    310.11 [#/sec] (mean)
Time per request:       3.225 [ms] (mean, across all concurrent requests)
Percentage of the requests served within a certain time (ms)

リクエスト数だけ見ると310接続/秒です。プラグインなどが入っておらず、ページキャッシュも使用していない数値としては早いです。が、1000同時接続には遠く及びません。
では、CPUのcore数を増やしてみましょう。

8core 5GBメモリ

さくらのクラウドでは、一度電源断する必要はありますが、サーバの構成変更が可能です。
同じサーバを使用して、CPUとメモリのプランを変更し8coreにしてみます。
メモリ使用量には余裕があったので、一番小さい5GBの状態です。

[kusanagi@kusanagi ~]$ cat /proc/cpuinfo |tail -27

processor       : 7
vendor_id       : GenuineIntel
cpu family      : 6
model           : 63
model name      : Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz
stepping        : 2
microcode       : 0x1
cpu MHz         : 2294.704
cache size      : 4096 KB
physical id     : 7
siblings        : 1
core id         : 0
cpu cores       : 1
apicid          : 7
initial apicid  : 7
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb lm c
onstant_tsc arch_perfmon nopl eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f1
6c rdrand hypervisor lahf_lm abm fsgsbase bmi1 avx2 smep bmi2 invpcid xsaveopt
bogomips        : 4589.40
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

[kusanagi@kusanagi ~]$ ab -n 5000 -c 500 http://XXX.XXX.XXX.XX/ 2> /dev/null | grep -i requests
Complete requests:      5000
Failed requests:        0
Requests per second:    625.22 [#/sec] (mean)
Time per request:       1.599 [ms] (mean, across all concurrent requests)
Percentage of the requests served within a certain time (ms)
[kusanagi@kusanagi ~]$ free -h
              total        used        free      shared  buff/cache   available
Mem:           4.8G        876M        3.6G        8.5M        447M        3.8G
Swap:          4.0G          0B        4.0G

4coreと同様にabテストを実施すると、625接続/秒と4core比較で倍の数字になっています。

16core 12GBメモリ

さらにcore数を倍の16 core にしてみます。

[kusanagi@kusanagi ~]$ cat /proc/cpuinfo |tail -27

processor       : 15
vendor_id       : GenuineIntel
cpu family      : 6
model           : 63
model name      : Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz
stepping        : 2
microcode       : 0x1
cpu MHz         : 2294.690
cache size      : 4096 KB
physical id     : 15
siblings        : 1
core id         : 0
cpu cores       : 1
apicid          : 15
initial apicid  : 15
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb lm c
onstant_tsc arch_perfmon nopl eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f1
6c rdrand hypervisor lahf_lm abm fsgsbase bmi1 avx2 smep bmi2 invpcid xsaveopt
bogomips        : 4589.38
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:
[kusanagi@kusanagi ~]$ ab -n 5000 -c 500 http://XXX.XXX.XXX.XX/ 2> /dev/null | grep -i requests
Complete requests:      5000
Failed requests:        0
Requests per second:    1204.34 [#/sec] (mean)
Time per request:       0.830 [ms] (mean, across all concurrent requests)
Percentage of the requests served within a certain time (ms)
[kusanagi@kusanagi ~]$ free -h
              total        used        free      shared  buff/cache   available
Mem:            11G        1.1G         10G        8.5M        465M         10G
Swap:          4.0G          0B        4.0G

ここで、ようやくkusanagi.tokyo を超える、1200 接続/秒が出ました。
ちなみに、この状態で処理速度を確認すると、以下のようでした。

少しは早いですが、18msと kusanagi.tokyoに比べて3倍ほど違います。使用されているプラグインなども考慮すると、もっと性能差があるはずです。

まとめ

以上の結果をまとめると、以下のことがわかりました。

  • KUSANAGIはそもそも早い
  • CPU core数を増やすと、同時接続数が多くなる
  • CPUの性能(Hz数など)を良くすると、表示速度が速くなる

ただし、上記の数値はWordPressを入れた直後のテーマやプラグインをあまり入れていない状態の数値なので、実際には同時接続数や表示速度は悪くなります。
ネットワークスピードによっても異なるので、参考程度に思っていただければと思います。
また、今回メモリはあまり使用していませんが、記事数が増えたりプラグインを使用するとメモリ使用量は変わります。KUSANAGIではメモリ4GB以上を推奨していますが、より多い同時接続数を求める場合は、MySQLやPHPのメモリチューニングが必要です。

なお、この数値は、ページキャッシュを使用していない数値です。
記事の更新が頻繁ではない場合、ページキャッシュを使用することで格段に同時接続数・表示速度を向上できますので、合わせてお試しください。

Follow me!

Leave a Reply

Your email address will not be published. Required fields are marked *