ElectronとNavigation Timingによるレンタルサーバーのレスポンス性能測定

これまでにhostingstock.netではレンタルサーバーの性能評価を実施しています。この記事のタイトルは「レスポンス性能」となっていますが、他にも「サーバーの処理性能」と「ファイル転送性能」を測定しています。

2年間ほど実施してきましたが、これまでの方法では測定しにくい環境を備えるサービスが登場してきたこともあり、大幅に測定方法を変更しました。

Webサイトの表示速度(レスポンス性能)

レンタルサーバー選びで最も重要なことは「Webページがどれだけ速く表示されるか」でしょう。 データベースやマルチドメインが無制限など、いかに機能が充実していても「エラーが発生しやすい」「レスポンスが悪い」と意味がありません。 自分を訪問者に置き換えれば、なかなか開かないWebサイトがストレスとなることは容易に想像できます。さらに遅いレスポンスはSEO的にもマイナス要因です。

測定対象の選定

測定対象は以前と同様に「WordPress」によるサイトとしています。 理由は明快であり、国内はもちろん世界中でもシェアの高いCMSだからです。 マイナーなCMSや独自サイトを対象とする意味はないでしょう。

W3Techsによると、世界中のWebサイトの46.6%がCMSを使用しており、そのなかでWordPressが「58.5%」を占めています。世界中の1/4のサイトがWordPressを利用していることになります。

OpenSourceCMS.comによる調査では、オープンソースのCMSに限定すると「70%」のシェア率となっています。

Webページの構成

Webページの構成はHTTP Archiveのデータを基準にしています。 詳しくはこちらの記事を参考にしてください。

  • 対象サーバーのみ測定するために、Gravatarを無効にするなど、外部ドメインへのアクセスは発生しないようにします。
  • 最新のテーマを採用します。この記事作成時はWordPress4.7で提供される「Twenty Seventeen」となります。

ページを構成するファイルは採用するテーマにより若干変化しますが、「Twenty Seventeen」の場合、以下の様になります。

ファイル構成
ファイル数は51、合計ファイルサイズは約2.5MB
WordPressの標準ファイル
JS (1KB, 7.5KB, 9.8KB, 94.9KB, 5.6KB, 683B, 1.3KB, 11.1KB) / JPG (112.1KB) / CSS (79.8KB)
コンテンツ
HTML (65.9KB) テキスト約3,000文字を含む / JS (28KB x10) / CSS (196B) / GIF (31.1KB x7) / JPG (75KB x13) / PNG (77KB x8) / Font (62.2KB)

このページ(記事)とは別に、2,000文字から3,000文字のランダムな記事を730件投稿済みの状態にしてます。 毎日1件ずつ投稿して、2年分のデータが格納された状態での測定となります。 一般的なブログなら十分な数でしょう。

Navigation TimingとElectron

以前はPHPのcURL関数(libcurl)による擬似的な測定でした。 今回の変更では、実際のWebブラウザでアクセスした状況と近づけるために、Node.jsとElectronを利用しています。 Electronは実行エンジンにChromiumを採用しており、測定結果はChromeでアクセスしたときと近い結果となるでしょう。

このような測定にはWebkitを採用するPhantomJSの利用が定番ですが、最近の動向を見ていると将来性に不安があります。 さらにシェアの低いWebkitよりは、圧倒的シェアを持つChromium(Chrome)を選択するべきでしょう。

そのためElectronを採用するNightmareの利用も考えましたが、ここまでの機能は不要なためNightmareとほぼ同じ機能を独自に実装しています。 長期的な測定に利用するため、安易に(いつ開発が止まるか分からない)第三者のライブラリは使いたくないという理由もあります。 Electronについては数年は問題ないでしょう。

Electronを採用することで、今後の標準となる「HTTP/2」の測定にも対応できます。 cURLもHTTP/2に対応していますが、現時点ではパフォーマンスに問題があります。

さらにNavigation Timing APIにより詳細なデータを取得できます。 詳細は省きますが、DNSのLookup時間や、最初のレスポンスにかかった時間などを確認できます。 数年以内にNavigation Timing 2に置き換わる予定ですが、現段階では安定した(枯れた)仕様を採用します。

Reponse: responseEnd - connectStart
DOM: domComplete - connectStart

測定結果は上図のようにグラフで表示します。一時的な測定は無意味なため、基本的に7日間の継続した測定となります。

Responseは最初のレスポンスが帰ってくるまでの時間です。つまり、HTMLドキュメントを取得するための時間です。 静的ページと動的ページ(WordPress)を同時に測定すれば、PHPやデータベースの処理性能の傾向が分かるでしょう。 DOMはHTMLドキュメントの取得から解析、さらに解析時に見つかったリソース(画像など)の読み込みが終わるまでの時間(onloadイベント発行時)です。

まとめ

バックボーン(ネットワーク性能)を含む総合的な評価となります。

当然、この測定方法ではクライアント側(測定元)のハードウェアやネットワークの性能により結果が変化します。 それはどのような測定方法や環境でも同じでしょう。

あくまでも比較による相対的な評価となります。他にも、継続的に測定することで安定性などの確認ができるでしょう。

サーバーの処理性能

従来の測定方法
100件の「ランダムな3,000文字/記事」の生成、および、投稿と削除
WordPressの標準関数(wp insert post、wp delete post)を利用

この方法でもサーバーの性能差をはっきりと確認でき、評価方法としては問題ありませんでした。 しかし、レンタルサーバーを利用する目的はWebサイトの運営であり、訪問者に快適なWebサイトを提供できるかが重要です。

そのため、総合的な処理性能(読み込み性能)の評価に変更しています。 測定内容は、レスポンス性能測定に利用したWordPressサイトを規定回数読み込むのに要した時間です。

ループバックで測定することで、レスポンス性能測定からネットワーク性能を除いたものとなります。つまり、サーバーの処理性能のみを対象とした測定です。ほとんど影響はないと思いますが、DNS Lookupの処理が含まれないようにしています。

HTTPクライアントで測定スクリプト(PHP)をキックしています。理由は直接PHPを実行するとWebサーバーを経由しないため、モジュールやCGIの差を確認できないためです。 さらに、最近ではApache以外のWebサーバー(NginxやLiteSpeed)を採用するサービスもあるため、Webサーバーを経由することで総合的な評価ができます。この方法ならWordPressに限らず、他のCMSによる評価も容易です。

当然ですが、総合的な測定となるため「データベースが遅い」などのボトルネックを確認できなくなります。 しかし、それはサービス事業者側が気にすることであり、利用者&訪問者にとっては、Webページが速く表示されれば何の問題もないのです。

ベンチマークツールについて

ab(Apache Bench)での測定結果を掲載しているサイトを見かけます。

ローカル環境で確認すれば分かりますが、この(これら)ツールは負荷テストを目的としたツールであり、設定によってはサーバーに過大な負荷をかけます。 使い方を間違えば「DoS攻撃」と何ら変わりません。 他の利用者の迷惑となるため、安易に共用サーバーの評価に利用すべきではありません。

このようなツールでの測定は、負荷が高すぎるため継続的な測定に向きません。 一時的な測定に意味がないことは、これまでの測定結果より明らかです。 意図的に良い(悪い)評価を得たければ、何度か測定して(都合の)よい結果だけ採用することもできます。

hostingstockでの測定方法もスレッド化すれば、負荷テストツールと同様の効果が得られます。しかし、他の利用者に迷惑をかけてまで実施する意味はありません。

このような単純な方法でも、処理時間が短いほど処理性能が(相対的に)高いことがわかります。何人(規定回数)かが連続してアクセスしたのと同等であり、通常のサイト運営でも普通の状況です。継続的に測定しても問題となりません。

ファイル転送性能

FTP、FTPS、SFTPによるアップロードとダウンロードの性能を評価します。

転送するファイルは、Webサイトのレスポンス性能測定の対象ページ(WordPress)を構成するファイル群(51Files, 2.5MB)です。

FTPクライアントの中には複数のコネクションにより、複数のファイルを同時に転送できるものがあります。 そのため、サーバー側が複数の同時接続を許可していれば、より速く転送できます。

今まで採用していたPHP(cURL関数)でも、(やや擬似的な)並列転送により測定していました。 しかし、一部パラメータの調整で測定値が変動するなど、評価には使いにくいものでした。 PHP7ならコネクションを管理する機能が提供されますが、(まだ)パフォーマンスが安定しません。

そこで、スレッドとFTPを標準で備えるPythonに変更しています。

ファイル転送性能はおまけ的な評価であり、レンタルサーバーの選択理由とはなりません。 特にWordPress等のCMSでサイトを運営するなら、FTPの利用頻度は低く、たまに利用するだけなら気になることもありません。 独自Webサイトの開発など、頻繁にファイルを更新する用途であれば参考となるでしょう。

関連記事

BLOG

UPDATE