
【5分でわかる】GTM(Googleタグマネージャー)の設定方法
インターネット広告
2025.02.03
更新日:2023.03.14
公開日:2017.09.04
ワードプレスで記事を沢山書くと自然とアクセス数もアップすると思います。また、アクセスが集まったら直帰数やサイト滞在時間が課題としてあがりやすいはずです。該当項目が課題になると、サイトを訪問してくれたユーザーさんにストレスなく楽しくサイトを閲覧してもらうために、javascriptを使った非同期通信などが増加していく事もしばしば。
そんなこんなでやっと訪問者数が伸びて、滞在時間・滞在ページ数が向上して来たときに突然発生するのが、サーバーが負荷を捌ききれないという事件です。
見に来てくれたユーザーさんに満足してもらう為にいろんな施策を重ねてきたのに「サイトが重くて直帰」「サーバーがアクセスを捌ききれずにエラー画面」なんてパターンになってしまうと非常に残念です。
打開策として「秒間1000リクエストをページキャッシュ非使用で実現する世界最高速クラスのWordPress実行環境」と公式サイトに記載のある「KUSANAGI」を試そうと思います。
実際にいろんなレビュー記事でも速度が速いと評価もよさそうです。レビューを参考にはさせて頂きますが、実際に確認する事が大切な業界なので、実際に速度検証してみました。
速度検証 参考・参照元:https://datahotel.io/archives/4354
そもそもKUSANAGIって何なんだ?と思う方も多いと思います。簡単にいうと「ワードプレスを高速で動作する環境(サーバー)」です。サーバーという単語を使ってしまうと色々ご指摘を受けそうですが、細かい言い回しは目をつぶってください。
例えば、お客さまから、「Aという商品に関するサイトを制作してほしい。ブログの様な記事を更新していく仕組みも入れて記事をどんどん追加したい」というオーダーを頂き、そのオーダーに対しワードプレスで制作しようとなると…
すごく大雑把ではありますが、上記のような流れになると思います。もし、「ページをもっと早く表示してほしい!」、「アクセスが多いと思うので上手くお願いします!(出来るだけ低コストで)」などのオーダーもあった場合、ワードプレスのカスタマイズを設定したり、サーバー設定の見直しなどの作業が発生します。
もちろんお仕事なので、間違いなく頑張るわけですが、最初から全部用意されているサーバーがあれば、そちらを使いたくなるのも当たり前です。その、最初から全部用意されているサーバーというのが「KUSANAGI」です。
公式サイト:https://kusanagi.tokyo/
「秒間1000リクエストをページキャッシュ非使用で実現」キャッチが良いですね。本当にレビューサイトの様な良い結果が出るか、速度検証を行ってみる事にします。
KUSANAGIを導入するには、KUSANAGIを使えるサーバー会社のプランを契約する必要があります。
などなど、メジャーなサーバー会社のVPSやクラウドなら、ほとんどが導入可能のようです。簡単に考えると、有名なサーバー会社で共有サーバー以外のプランをレンタルすれば大体使えるイメージです。詳しくは公式サイトURLで確認頂けます。
KUSANAGIが使えるサーバーサービス :https://kusanagi.tokyo/cloud/
共有サーバー以外のプランとは、VPSやクラウドプランの事です。契約しようとしているサーバー会社でKUSANAGIが使えるか不安な場合は、対象のサーバー会社に直接問い合わせするのが一番安心です。
今回の速度検証では、同じインフラ環境でサーバー構成が違うという環境が個人的に一番作りやすいAWSで行います。
速度検証を行ったのは、以下の3環境です。
1. Centos7 + Apache + php7 + MariaDB
一般的なサーバー構成(ノーチューニング)
2. Centos7 + Nginx + php7 + MariaDB
1ほどではないが、一般的なサーバー構成(ノーチューニング)
3. KUSANAGI (Centos7 + Nginx + php7 + MariaDB)
1、2と同じPHPのバージョンとウェブサーバーOSでKUSANAGIを設定しました。
ほとんど同じに見えるとおり、実際使ってるソフトウェアはほとんど同じです。良くチューニングされたサーバーか、そうでないサーバーかという感じです。車でいうと1、2はオートマかマニュアルかが違うだけで、3だけ2をベースにレース用に改造されているというイメージです。
速度検証には、参考記事で使われていた物と同じApache Benchというツールを使いました。理由は一番準備が必要なく、コマンド1行で動くからです。速度テストを行うのは、以下キャプチャのとおり最初から用意されている記事の見出しではなく、本文ページです。
本当に速かったらいいなぁーと思い検証した結果は以下のようになりました。「テスト1 < テスト2 <テスト3」の関係性でサーバーにかける負荷は高くなります。
※環境名は、以下の様に省略表記します。
テスト1(リクエスト数1000、同時リクエスト数200)
トラック(環境) | バス(環境2) | バイク(環境3) | |
---|---|---|---|
総リクエスト数 | 1000 | 1000 | 1000 |
失敗リクエスト数 | 84 | 167 | 0 |
処理数/秒 | 44.5 | 93.0 | 278.8 |
平均処理時間 | 0.022秒 | 0.010秒 | 0.003秒 |
同時リクエスト 処理時間 | 4.49秒 | 2.15秒 | 0.73秒 |
総処理時間 | 22.47秒 | 10.75秒 | 3.652秒 |
テスト2(リクエスト数3000、同時接続数200)
トラック(環境) | バス(環境2) | バイク(環境3) | |
---|---|---|---|
総リクエスト数 | 3000 | 3000 | 3000 |
失敗リクエスト数 | 112 | 257 | 0 |
処理数/秒 | 72.8 | 180.5 | 260.6 |
平均処理時間 | 0.013秒 | 0.005秒 | 0.004秒 |
同時リクエスト 処理時間 | 2.75秒 | 1.10秒 | 0.77秒 |
総処理時間 | 41.20秒 | 16.62秒 | 11.50秒 |
テスト3(リクエスト数5000、同時接続数200)
トラック(環境) | バス(環境2) | バイク(環境3) | |
---|---|---|---|
総リクエスト数 | 5000 | 5000 | 5000 |
失敗リクエスト数 | 209 | 322 | 0 |
処理数/秒 | 68.8 | 239.5 | 272.4 |
平均処理時間 | 0.014秒 | 0.004秒 | 0.003秒 |
同時リクエスト 処理時間 | 2.90秒 | 0.83秒 | 0.73秒 |
総処理時間 | 72.69秒 | 20.87秒 | 18.35秒 |
5000リクエストを上限に絞って細く刻みましたが、傾向として、バイクKUSANAGIが一番安定して速い結果に終わりました。リクエスト数が増えると段々とバスNginxと差が縮まってきているように見えますが、失敗したリクエスト数が0のバイクKUSANAGIの圧勝だと思います。
トラックApacheに関しては3回とも一番遅かったですが、バスに比べて失敗数が常に半分くらいだったので安定性では上回っているような感触があります。バイクKUSANAGIが失敗する所を見たいので、単体でテストを続行してみました。
テスト4(リクエスト数10000、同時接続数200)
バイク(環境3) | |
---|---|
総リクエスト数 | 10000 |
失敗リクエスト数 | 0 |
処理数/秒 | 286.2 |
平均処理時間 | 0.003秒 |
同時リクエスト処理時間 | 0.69秒 |
総処理時間 | 34.93秒 |
テスト5(リクエスト数10000、同時接続数500)
バイク(環境3) | |
---|---|
総リクエスト数 | 10000 |
失敗リクエスト数 | 112 |
処理数/秒 | 168.2 |
平均処理時間 | 0.006秒 |
同時リクエスト処理時間 | 2.79秒 |
総処理時間 | 59.46秒 |
同時リクエストを2.5倍に増やした所で若干の失敗が発生しました。とはいえ非常に安定して速いですね。他サイトでの検証結果は事実で、公式サイトの秒間1000リクエストも伊達ではなさそうです。
速度検証をして自分の目で性能を確かめると、本当に良く出来たサービスだと実感しました。
【KUSANAGI導入メリット】
【KUSANAGI導入デメリット】
良くも悪くも、お客さまの理解も必要であるというのが感想です。共有サーバーを指定してご依頼頂く事もあるので、サーバーから選んで欲しいという場合に「こういう選択肢もありますよ」という提案からだと思います。
ただ、個人的には使ってみたいと思います。工夫すればスケールアウトも出来るようなので、突然のトラフィック増加があっても安心です。