このブログは、Raspberry Pi 4 Model BをWebサーバーとして稼働させて公開しています。
低価格、省電力の代わりに非力なので、ブログがワンテンポ遅れて表示されたり、画像圧縮やアップロードに時間がかかることもあります。
今回はそんなラズパイをWebサーバーにした時の負荷が、どのくらいかかっているかを調べていきたいと思います。
サーバー構成
サーバー機：Raspberry Pi 4 Model B （メモリ4GB）
ストレージ：Samsung 980 500GB （MZ-V8V500B）
OS：Raspbian Lite 32bit
Webサーバー：Apache2
ブログソフト：WordPress
テーマ：Cocoon
回線：BBIQ光回線1Gbps
導入しているプラグイン
Akismet Anti-Spam: Spam Protection
Broken Link Checker
Brozzme DB Prefix change and DB Tools addon
Code Profiler
Contact Form 7
Edit Author Slug
EWWW Image Optimizer
GTM4WP
Health Check & Troubleshooting
Site Kit by Google
UpdraftPlus – Backup/Restore
WP-Optimize – Clean, Compress, Cache
WP Cerber Security, Anti-spam & Malware Scan
WP File Manager
WP Htaccess Editor
WP Mail SMTP
WP Multibyte Patch
XML Sitemap Generator for Google
プラグインの負荷比較
まずは、プラグイン別の負荷を調べます。
ラズパイのCPUは1.5GHzのクアッドコアです。軽いプラグインの処理なら平気ですが、スペック的に負荷の高いプラグインはブログ全体が重くなるので外していきます。
調べるために使用したプラグインは「Code Profiler」です。導入しているプラグインの負荷率をグラフにしてくれる優れものです。
横軸が実行時間（読み込み時間）です。
一番負荷が重いのがWordPressのテーマとして使用しているCocoonとなりました。
それでも実行時間は0.648秒なのでほとんど負荷はないかと思います。
ちなみに、有名なプラグインの「Jetpack」を導入すると・・・
周りのプラグインを巻き込んで、とんでもない負荷になりました。
Cocoonは実行時間0.648秒から123秒に伸びました。Jetpack自体は726秒でした。
Jetpackはサイトダウン時の通知機能以外は使っておらず、負荷のことを考えるとデメリットの方が大きいので削除します。
Code ProfilerはPHP コードを分析する必要があるため、キャッシュ、CDN、PHP OPcache などのあらゆる種類の Web サイト最適化を除外し、無効化して測定しています。そのため、グラフに表示される実行時間（読み込み時間）は、実際のサイトの読み込み速度と異なる場合があります。
（更新）WP-Optimizeの負荷上昇
再度、プラグインの負荷を調べたところ、WP-Optimizeの負荷が上がっていました。
キャッシュを生成、JavaScriptやCSSを圧縮する負荷がラズパイに対して大きかったのかは分かりませんが、前回調べた時の負荷はそうでもなかったので、使用する過程で負荷が上下したり、導入したプラグイン同士の相性の問題で変わってくるのかもしれません。
（追記）Google Chrome 検証ツール
Google Chromeには開発者向けの検証ツールが実装されています。
そこでサイトを読み込んだ時の状況が詳細に記録され、分析することができます。
下の画像は、「4G回線のAndroidスマホでChrome（キャッシュ無効）を使用」という設定をエミュレートしてサーバーにアクセスした時の状況です。
注目すべきは「サーバーの応答を待機しています」という項目です。
当サイトは「WP-Optimize」プラグインを用いてキャッシュを有効化しています。
2回目以降のアクセスはキャッシュが効いているのかレスポンスは悪くないです。
しかし、初回アクセス時はサーバーが応答するまで3秒以上かかっています。
ふと、プラグインの負荷を思い出し、WP-Optimizeを無効化してみました。
すると・・・
レスポンスの速度が1.28秒まで改善されました！
でも、応答速度が改善されたのはいいですが、キャッシュが無効化されJavaScriptやCSSが圧縮されていないので、総合的にはサイト全体に対してのアクセス速度が遅くなってしまいます。
う〜ん、諸刃の剣ですね・・・。
Google PageSpeed Insights
続いては、サイトスピードを計測してくれるGoogle PageSpeed Insights。
モバイルは54点、パソコンは75点でした。モバイルの点数はちょっと低めですね。
Total Blocking Timeがパソコンと比べて数字が大きくなっています。
【Total Blocking Time】
マウスのクリック、画面のタップ、キーボードの押下などのユーザー入力に対するページの応答がブロックされている合計時間のこと
Total Blocking Timeが遅くなる原因として、JavaScriptが大きく関係しています。
この項目は不要なJavaScriptを削除したり遅らせたりすることで改善することができます。
このブログの場合、GoogleアナリティクスやGoogle AdSenseなどのコードを入れているのでその影響が出ています。
もちろん、高価なサーバー用CPUと大量のメモリを積んでいれば、全ての項目において素晴らしい点数が取れるでしょう。
もしラズパイサーバーよりも高得点を目指すのであれば、エックスサーバーやConoHaのようなレンタルサーバーを安く借りるのが一番確実です。スペックは段違いに良いですからね。
NetdataでCPU使用率や通信量、読み書き速度を見る
次は、Netdataというソフトを用いて負荷を見ていきます。Netdataはリアルタイムで動くので、全体の動きが把握しやすいのが大きなメリットです。
Netdataはサーバーにインストールすることで、ブラウザ経由でシステム状況を詳細に調べることができます。
次の画像は、モバイル4G回線で当ブログにアクセスした時のCPU使用率です。
実際に負荷がかかるのは一瞬なのでアクセス数が低いうちはまだ許容範囲ですが、1日数百人から閲覧されるようになれば、サーバー自体を見直さないといけないかもしれません。
次の画像は一番使用頻度が高そうな下書き保存時の負荷です。（※設定の関係でキロバイトとメガバイトがバラバラに表示されています。）
下書き保存時の負荷率は、どれくらいの量の記事を保存するかで大きく変わると思います。それでもCPU使用率が24％なのは少し高めな印象があります。
最後はテーマカスタマイズ画面をロードした時の画像です。
こちらも上記の２つの画像と比べて似たような負荷となりました。特に目立った変化はありません。
ロードするときのCPU使用率は、概ね20～30％ほどと考えてよさそうです。
また、メモリ使用率が平均で10％～15％と比較的余裕があったので、その点は安心しました。ブログの規模が小さいうちは4GBで十分だと思います。
それと当然のことではありますが、画像が多く載せてあるページを読み込む時はディスクの読み込み量が増えて、アップロード量も増えていたので、画像は圧縮したりサイズを小さくするのに越したことはないと思いました。
画像のデータ量が減らせれば、CPU、ディスク、メモリ、通信量の負荷が下がるので、一石四鳥です。
総評：十分実用的だが、アクセス集中時の負荷が未知数
ある程度のレスポンスの遅さには目を瞑って、重いプラグインは導入せず、キャッシュやCSS・JavaScriptの圧縮などを駆使して最適化すれば十分使える範囲だと思います。
しかし、今後アクセス数が増えてくるとすぐに高負荷の状態になると思うので、その時はサーバーを変えないといけないかもしれません。
メモリは十分余裕があるので、問題はCPUになります。もし腕のある人なら、複数のラズパイを繋げてクラスタで運用することでこの問題は解決できると思います。そこまでラズパイに拘るならの話ですが・・・。
その他、新しく気づいた点があれば、都度更新していきたいと思います。
コメント