カテゴリー: WordPress

投稿日: 更新日:2020年5月14日 Blog, Linux, WordPress

ThinkCentre M75q-1 TinyのUnixBench

UnixBench を計測したので貼り付けておくことに。OSは、Fedora32 Server です。RAM8G、SSDはM.2 の128GB です。電源はまだノーマルの標準電源を使っています。iso download は以下。

Fedora 32: Standard ISO image for x86_64
https://getfedora.org/ja/server/download

Fedora-Server-dvd-x86_64-32-1.6.iso をEtcherでUSBへ。デフォルトのインストとupdate した状態です。

# uname -r
5.6.6-300.fc32.x86_64
# cat /etc/redhat-release
Fedora release 32 (Thirty Two)

UnixBenchのインストールは以下で。

dnf -y install perl perl-Time-HiRes make gcc git
cd /usr/local/src/
git clone https://github.com/kdlucas/byte-unixbench
cd byte-unixbench/UnixBench
./Run

————————————————————————
Benchmark Run: 木 5月 14 2020 21:04:49 – 21:32:47
8 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables 49030625.4 lps (10.0 s, 7 samples)
Double-Precision Whetstone 8053.1 MWIPS (10.0 s, 7 samples)
Execl Throughput 7274.6 lps (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 1361719.5 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 393986.4 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 2712326.9 KBps (30.0 s, 2 samples)
Pipe Throughput 2370670.8 lps (10.0 s, 7 samples)
Pipe-based Context Switching 320451.7 lps (10.0 s, 7 samples)
Process Creation 11315.5 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 6747.2 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 2979.2 lpm (60.0 s, 2 samples)
System Call Overhead 3484938.2 lps (10.0 s, 7 samples)

System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 49030625.4 4201.4
Double-Precision Whetstone 55.0 8053.1 1464.2
Execl Throughput 43.0 7274.6 1691.8
File Copy 1024 bufsize 2000 maxblocks 3960.0 1361719.5 3438.7
File Copy 256 bufsize 500 maxblocks 1655.0 393986.4 2380.6
File Copy 4096 bufsize 8000 maxblocks 5800.0 2712326.9 4676.4
Pipe Throughput 12440.0 2370670.8 1905.7
Pipe-based Context Switching 4000.0 320451.7 801.1
Process Creation 126.0 11315.5 898.1
Shell Scripts (1 concurrent) 42.4 6747.2 1591.3
Shell Scripts (8 concurrent) 6.0 2979.2 4965.3
System Call Overhead 15000.0 3484938.2 2323.3
========
System Benchmarks Index Score 2154.9

————————————————————————
Benchmark Run: 木 5月 14 2020 21:32:47 – 22:00:43
8 CPUs in system; running 8 parallel copies of tests

Dhrystone 2 using register variables 236941205.1 lps (10.0 s, 7 samples)
Double-Precision Whetstone 51602.2 MWIPS (9.3 s, 7 samples)
Execl Throughput 28775.4 lps (29.5 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 1419459.3 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 363611.3 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 3235463.9 KBps (30.0 s, 2 samples)
Pipe Throughput 13054418.9 lps (10.0 s, 7 samples)
Pipe-based Context Switching 1339045.5 lps (10.0 s, 7 samples)
Process Creation 62894.8 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 28423.5 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 4298.6 lpm (60.1 s, 2 samples)
System Call Overhead 15655142.3 lps (10.0 s, 7 samples)

System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 236941205.1 20303.4
Double-Precision Whetstone 55.0 51602.2 9382.2
Execl Throughput 43.0 28775.4 6692.0
File Copy 1024 bufsize 2000 maxblocks 3960.0 1419459.3 3584.5
File Copy 256 bufsize 500 maxblocks 1655.0 363611.3 2197.0
File Copy 4096 bufsize 8000 maxblocks 5800.0 3235463.9 5578.4
Pipe Throughput 12440.0 13054418.9 10493.9
Pipe-based Context Switching 4000.0 1339045.5 3347.6
Process Creation 126.0 62894.8 4991.6
Shell Scripts (1 concurrent) 42.4 28423.5 6703.7
Shell Scripts (8 concurrent) 6.0 4298.6 7164.3
System Call Overhead 15000.0 15655142.3 10436.8
========
System Benchmarks Index Score 6422.2

うほ！　シングルで2154.9、マルチCPUで6422.2。なかなか優秀じゃないですか！
自宅サーバにはもったいないくらいですね。

投稿日: 更新日:2020年3月26日 AdSense, ClassicPress, WordPress

AdSense を設定してみるがサブドメインあかんみたい？

さて、最近このサイトを自宅サーバに引っ越すためあれこれ準備をしています。

自宅サーバになったら、AdSense もやってみたいなと思って登録しようと思いました。

Google AdSense
https://www.google.com/adsense/

が、登録中、以下のようになります。

Google AdSense

マニュアルによれば、サイトの追加からできるようですが、これをやるにはまずメインのドメインを追加して認証させないとだめみたいです。

サイトリストでサブドメインを追加または削除する
https://support.google.com/adsense/answer/9130110?hl=ja

メインのドメインっていうと、gpl.jp や www.gpl.jp というものですがこれはとりあえず運用していません。しかし、とりあえずサイトを起動させておかないと許可が降りないのかな？　ま、そういうのはやってみればわかりますね。やってみましょう！

次のステップでは、マルチサイト機能を使ってメインドメインを動作させてみようと思います。ClassicPress でもできるはずですので動作確認も兼ねてみましょう。あと、ローカルの MAMP Pro 環境で Let’s Encrytの SSL をワイルドカードで出来るかやってみようと思います。

・ClassicPress で マルチサイトを立ち上げる

・MAMP Pro 環境でLet’s Encryt のワイルドカードSSLを設定

とりあえず、このようなネタをあげる予定です。

 

投稿日: 更新日:2020年3月20日 ClassicPress, WordPress, 高速化

高速化その３：画像圧縮してみた！次世代画像フォーマット「WebP（ウェッピー）」を使う

以前、スマホからのアクセスをもっと速くしたいなと思っていたのですが、高速化その３で手をつけることにしました！
まず、手をつける前の状態は以下です。

E383a2e3838fe38299e382a4e383abe382b5e382a4e38388e381aee9809fe5baa6e38292e6af94e8bc83e38197e381bee38197e38287e38186

はい、2.2秒かかっていたようです。レポートには、いろいろ書いてありますが画像の項目は以下のようにアドバイスされていました。

次世代フォーマットで画像を配信する
JPEG 2000、JPEG XR、WebP で画像をエンコードすると、読み込み時間が短くなり、モバ
イル通信のデータ量も少なくすることができます。フォールバック用に PNG 画像や JPEG 画
像も用意し、未対応ブラウザにはそちらを配信するようにしましょう。

ということで、WebP に変換することことにしました。変換には方向性として２つあり、１つはクラウドサービスでWebPに変換してもらうのを利用する方法。もう１つは、自サーバの機能を使ってWebP に変換する方法です。後者は、PHPがimagemagic をサポートしていてそのフォーマットにWebP がある場合に有効です。

phpinfo.phpにアクセス　→ サーバー設定のレポートを見る。
「imagick」項目の “ImageMagick supported formats” という行に「webp」があればサポートしています。

現在はまだテストサーバで mamp でやっていますので、これはサポートしていないことがわかりました。自分でサーバを作るときは対応させる予定ですが、今のところは外部クラウドのWEBサービスを使って高速化がどのくらい進むか確認してみようと思います。

パッと思いつくのは、https://tinypng.com/ のサービスです。

TinyPNG Compress PNG images while preserving transparency

これをWordPress（ClassicPressでも利用可）で利用するPlugin があるので使うことにします。

Compress JPEG & PNG images
https://ja.wordpress.org/plugins/tiny-compress-images/

Plugin を有効にして、API をゲット（月に500まで利用可）です。メディア設定の自動リサイズを無効にして、medium_large_size_h のパラメータも以下から0 にしておきます。

https://yourdomain/wp-admin/options.php

設定は以下のようにしておきました。

高速化 アリエクでポチった JunkHack と Compress JPEG PNG images アリエクでポチったJunkHack ClassicPress

どのくらい高速化が進んだか確認してみましょう！

モバイルサイトの速度を比較しましょう

結果、1.7秒です。0.5秒改善しましたね！

あとついでなので、Autoptimize プラグンで JS と CSS の最適化をしておきました。これは有名なんで説明は省略。

Autoptimize
https://ja.wordpress.org/plugins/autoptimize/

結果、高速化その３では最終的に、1.2 秒にまで改善できました。

モバイルサイトの速度を比較しましょう

あと、0.3秒ほど頑張れば１秒以下になって「速い」の部類に入るかと！　あとはサーバ側でがんばりましょうか。

・・・高速化その４　に続く

投稿日: 更新日:2020年3月18日 ClassicPress, WordPress, 高速化

高速化その２：ClassicPress を入れてテーマを調整

宅内サーバのテスト環境で、テーマの調整とClassicPress を試しにインストールしてみました。Classicpress logo wordmark gradient on transparent

enひかりの IPv6 トンネルもかなり有効だと思いますが、なかなか良いスコアが出たので記録しておきます。ちにみに、純粋なClassicPress にした速度向上というのはわずかです。テーマの部分が大きいかなという印象です。

PageSpeed Insights

Google の PageSpeed Insights の結果です。ずっと99% であと1% が上がらなかったのですが、画像の遅延読み込み（※1）を行なったら100% になりました。現在のWordPress.com 上にあるデータと変わりないのに、テーマとかWordPress 本体を ClassicPress にして enひかりの v6ひかり＋固定IPの環境にしただけです。 １秒未満なので、とりあえずは十分な結果がPCは出ていますね。ちなみに、開発環境は以下の通り。

WEB：NGINX1.13.2（MAMP Pro）
PHP：php7.4.1（MAMP Pro）
DB：MySQL 5.7.26（MAMP Pro）

Server CPU：AMD Ryzen 5 3600
RAM：32GB
DISK：SSD

CMS：ClassicPress 1.1.2
テーマ：Sustyバージョン: 1.0.0
WP Plugin：
　Akismet Anti-Spam 4.1.4
　AMP 1.4.4
　Broken Link Checker 1.11.11
　Catch Infinite Scroll 1.7
　Lazy Load 0.6.1
　Switch to ClassicPress 1.2.0
　WordPress インポートツール 0.7
　WP Super Cache 1.7.1

　※1・・・画像の遅延読み込みとは、ブラウザが最初に「スクロールせずに見える」ページの画像のみを表示し、スクロールしたときに画像を読み込むということです。これらを簡単に実現するため、Lazy Loadを使っていますがやり方はいろいろあるようです。

モバイル環境については、まだ向上の余地がありそうです。JS の調整がまだ残っています。

PageSpeed Insights

ClassicPress は、wordpress5.3.2 から switch-to-classicpress プラグインを入れて行いましたがなんのトラブルもなくできました。ClassicPress にして明確になったのが、jetpackプラグインはない方が絶対的に速いです。また、ストレージ容量が ClassicPress は20MB くらい減りファイル数も300くらい減りました。

今の所、可もなく不可もなくといったところでしょうか？　しかし、良いなと思うのは ClassicPressバージョン1.xは、長期サポート（LTS）バージョンということで安定して動作してくれそうな気がします。プラグインも同じようにインストールすることができて、動作するものは「Compatible with your version of ClassicPress」と表示されますので目安になりますね。

プラグインを追加 アリエクでポチったJunkHack ClassicPress

というわけで、方針としては ClassicPress を使っていくことにしました。そして、jetpackプラグインはもう使わないことにします。テーマは、Sustyをカスタマイズして使うことにします。

投稿日: 更新日:2020年3月17日 Linux, WordPress, 高速化

宅内サーバのWEBアプリと高速化のキャッシュ方法を検討！

自宅サーバに適用する構成について、最近のWebアプリ周りのサーバ側事情を調査していました。
まず、このブログを宅内で動作させるには WordPress を動作させることが必要です。で、その構成をどうするか検討することにします。以下のようなことを考えないといけないですね。

OS：Linux で動作させますが、どのディストロビューション
（CentOS とか Fedora とか ubuntuとか）にするか？
Web：NGINX とか apache とか。
PHP：PHP7 とか HHVM とか。またはその動作方法php_fpm とか、mod_php とか。
データベース：MariaDB とか、MySQL とか。

また以下の点については、趣味のブログなので作りながら考えていくことにします。

冗長性：これは当面、１台動作で考えないことにします。落ちたら、なるはやで復旧。
運用監視：外部監視をどうするか？
バックアップ：どっかにデータをバックアップしないとです。
保守：マシンが壊れた時、または停電時など。

めんど臭いですね！（笑）ま、当初からわかっていたことですが改めて書くと考えることが多いです。

で、改めて最新の動向も探りながら、ざっくり検討することにしました。動作させるマシンはもうすでに決定済みで、前回までに決めた Ryzen 5 Pro 3400GE が動作するマシンです。Kernel を最新にしたいということもあり、Fedora かubuntuあたりにしようかと思っています。

肝心の Webサーバは、NGINX + HHVM という構成が有力でしたがどうやら最近は事情が変わっているようです。2013年〜2014年に検討した時、HHVM の高速性にはびっくりしたのが印象的でした。24時間アクセス（vmで2台構成）のベンチマーク耐久テストでも落ちなかったのを覚えています。24時間で、400万PVを達成しました。1秒間に、約46回の処理をした計算になります。ま、その直後は vmホストのSSD がぶっ壊れましたが（笑）しかし、残念なことにHHVM は、今やPHPコードを動作させることができなくなったようです。

RIP WordPress and HHVM – We’ve Had a Good Run

ちょっとショックだったので、オフィシャルサイトのドキュメントも確認しておきました。HHVM v3.30　がPHPサポートの最終とのこと！ 2018/12/17 だって。もう１年以上前か。

Ending PHP Support, and The Future Of Hack

改めて最新の動向を見てみると、どうやら LiteSpeed というWEBサーバのほうが良さそうです。2015年のネタなので現在は状況が変わっているかもしれません。

PHP7 vs HHVM Benchmark Series 1: Hello World

そして、現在は HHVM よりもPHP7 が良い結果が出ているそうなので、LiteSpeed のオープンソース版である OpenLiteSpeed を使うことにしました。とりあえず、以下のような構成でいこうかと。openlitespeed-logo-1200x300.png

OS：Linux（Fedora 31 server）
Web：OpenLiteSpeed 1.6.x
PHP：PHP7.x
データベース：MariaDB10.x
WordPress代替：ClassicPress ★代替えの必要があるかちょっと使ってみる
キャッシュ：LiteSpeed Cache WordPress

LiteSpeed のWEBサーバと、WordPress のPlugin であるキャッシュ（LiteSpeed Cache WordPress）は専用設計のようです。そして、このキャッシュはWordPress代替のClassicPressでも動作するようです。

LiteSpeed Cache for WordPress
::
LiteSpeed Cache Works With ClassicPress

LSCache（青いグラフ）がそれみたいですが、速そうですね。

screenshot-1.png

また、OpenLiteSpeed と LiteSpeed との違いは以下に機能比較があります。

OpenLiteSpeed or LiteSpeed Enterprise?
https://www.litespeedtech.com/products/litespeed-web-server/editions

WordPress代替のClassicPress は一度、ローカルに入れて検討してみないとですね。

Get ClassicPress
https://www.classicpress.net/get-classicpress/

ということで、今後の課題が見えてきました。ちょっと目を話すとどんどん状況が変わるからこの業界は面白いんですよね！

投稿日: 更新日:2020年3月16日 cdn, enhikari, WordPress, 高速化

CDNを使わずWEBアクセスのロードタイムが１秒を切った！

ちょっと前に、このブログのロードタイム、１秒を切りたいと話していました。

スマホからの表示速度を1秒以下にしたい！

で、enひかりの固定IP配下に作ったテスト環境でこのブログと同等のデータを引っ越して速度向上を検討していました。まず、現在の結果から出してみたいと思います。モバイルサイトの速度を比較しましょう

3.8秒から、2.2秒までアップしました。スマホ表示にはまったく手をいれていませんが、1.6秒縮まりましたね！

また、PCでのアクセスは別サイトで計測しました。まずは現状の確認。

WebPageTest Test Result Tokyo junkhack gpl jp 03 16 20 02 26 41

「LoadTime」の部分が全体を表示するまでにかかっている時間です。では、検証用に立ち上げているサイトでも同様に見ていきます。

WebPageTest Test Result Tokyo hoge gpl jp 03 16 20 03 10 36

なんと、1秒を切っています！4.5秒からなんと0.98秒までアップしました。
CDN を使わなくてもここまでアップできるものなんですね。まだチューニングする部分はたくさんありますが、今年の夏引っ越しに向けて、あれこれ研究していきたいと思います。

今回速度の向上に関して、確認したことといえば以下となります。

・WordPress のテーマは軽いのがいい　→ Susty WP に変えた
・CDNは使っていないが、Jetpack のCDN機能を使いました　→ これはあまりよろしくないかも（要研究）
・表示を10から3に変えた　→ もっと見たい人はほぼいないし、見たければ検索なりしてくれるから
・回線をenひかりの IP固定 v6プラス の自宅サーバにしてみた　→ WordPress.com はデータセンターがUSにあります。v6網のバイパスはかなり有効！

CDN は、DNS の ns を切り替えないといけなしそれなりに弊害もあるのでたぶんやらないと思います。使わなくてもここまでできるなら、あとは微調整でもっと速くなるかもしれません。Jetpack のCDN機能を使った影響なのか、それ以外が原因なのかわかりませんが、以下のように空白の時間があります。

Latest Performance Report for http hoge gpl jp GTmetrix

ということで、ロードタイムが１秒を切ったという話でした。まだまだ研究する部分がたくさんありますので、継続してあれこれやってみたいと思います。