スマホサーバの構成をNGINX+php-fpm+mariadbの構成にしてWordPressを動かして速度を計測しておいた

NGINXとphp-fpm構成にしてみました。いつもの計測サイトです。

夜間のネットワークが一番空いている時なんで、速い感じでしょうか?

GCP東京リージョンからの、apache ab は以下。182/sec 〜!速っ 78秒かかっていたテストが5.5秒。あ、これWordPressのキャッシュ効かせる前でしたね。apache構成でも同じ条件でサイド計測しておかないと。

$ ab -n 1000 -c 100 http://jh.gpl.jp/
::
Server Software:        nginx
Server Hostname:        jh.gpl.jp
Server Port:            80

Document Path:          /
Document Length:        15997 bytes

Concurrency Level:      100
Time taken for tests:   5.479 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      16202000 bytes
HTML transferred:       15997000 bytes
Requests per second:    182.52 [#/sec] (mean)
Time per request:       547.887 [ms] (mean)
Time per request:       5.479 [ms] (mean, across all concurrent requests)
Transfer rate:          2887.87 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       16   20   6.5     19     149
Processing:    57  487  82.1    480     747
Waiting:       39  467  82.0    460     724
Total:         88  507  82.5    501     783

Percentage of the requests served within a certain time (ms)
  50%    501
  66%    531
  75%    544
  80%    551
  90%    578
  95%    642
  98%    702
  99%    738
 100%    783 (longest request)

まだ、SSLとか設定はこれからでパラメータなども未調整です。設定値は以下のサイトを大いに参考にさせていただきました。

NginxでWordPressを使う時の設定をまとめてみた

あとは、SSL設定をtermuxでどうやるかですね。自動化したいので、どんな感じの仕組みが動くんでしょうか。

あ、それからRapid START CDNのフェイスブックチャットに応答があったんで、もう一度試してみるかもしれません。

 追記

やっぱりWEBフォント読まないほうが速いんで、Autoptimizeで試験的にカットしてみました。

読み込むものが少なくなれば、表示するのも速いですね。WEBフォントがなくなることで、多少文字の表示は意図したものと違うことになりますが、快適に読んでもらえるほうが良いと思うので、とりあえずはWEBフォントは外す方向で。

あと、モバイル向けのスコアがかなり変わりました。

まぁ、そのうち気が変わるかもしれませんが。

Termuxのapache2+php7+mariadb10 環境でwordpressの表示スコア

とりあえず、1つの指標としてメモしておくことにします。まず、改善結果から。データ量は、今見ているこのブログの過去記事、約400件のデータでテンプレートは、Hew です。TOPの表示記事数は3です。スマホ側は、UmidigiF2にapache2+php7+mariadb10の環境となります。ClassicPressではなく、WordPress最新5.5.1です。

WebPageTest_Test_Details_-_Tokyo___jh_gpl_jp__-_09_06_20_18_04_20

改善前は以下です。

WebPageTest_Test_Details_-_Tokyo___jh_gpl_jp__-_09_05_20_15_15_05

2.2秒くらいから、1.3秒くらいまで改善しました。これは、キャッシュ化の効果です。キャッシュさせるのは、何がいいのか迷いましたが一番シンプルそうな、「Simple Cache」というのを使いました。

プラグイン_‹_JunkHack_—_WordPress

Jetpack の全ての機能を試していませんが、とりあえずは動いている感じです。設定も以下のように単純です。手動でのキャッシュ削除は設定画面の2箇所から可能です。

シンプルキャッシュ‹JunkHack_—_WordPress

nginx_1.19.2 と、php-fpm_7.4.9 の組み合わせでも確認してみたいですね。

Termuxパッケージ安定板
https://grimler.se/termux-packages-24/arm/

nginxの1.19.2 はオフィシャル側は 2020/08/11 に公開していて、termux 側は、8/18 なんでちゃんとメンテナンスされているようです。

とりあえず、apacheのhttpd.confのパッチは以下です。apache 2.4.46 のデフォルト設定ファイルとの差分です。

--- httpd.conf.org	2020-08-09 07:55:34.000000000 +0900
+++ httpd.conf	2020-09-06 01:56:57.560924026 +0900
@@ -63,8 +63,8 @@
 # Example:
 # LoadModule foo_module modules/mod_foo.so
 #
-#LoadModule mpm_prefork_module libexec/apache2/mod_mpm_prefork.so
-LoadModule mpm_worker_module libexec/apache2/mod_mpm_worker.so
+LoadModule mpm_prefork_module libexec/apache2/mod_mpm_prefork.so
+#LoadModule mpm_worker_module libexec/apache2/mod_mpm_worker.so
 LoadModule authn_file_module libexec/apache2/mod_authn_file.so
 #LoadModule authn_dbm_module libexec/apache2/mod_authn_dbm.so
 #LoadModule authn_anon_module libexec/apache2/mod_authn_anon.so
@@ -88,7 +88,7 @@
 #LoadModule cache_module libexec/apache2/mod_cache.so
 #LoadModule cache_disk_module libexec/apache2/mod_cache_disk.so
 #LoadModule cache_socache_module libexec/apache2/mod_cache_socache.so
-#LoadModule socache_shmcb_module libexec/apache2/mod_socache_shmcb.so
+LoadModule socache_shmcb_module libexec/apache2/mod_socache_shmcb.so
 #LoadModule socache_dbm_module libexec/apache2/mod_socache_dbm.so
 #LoadModule socache_memcache_module libexec/apache2/mod_socache_memcache.so
 #LoadModule socache_redis_module libexec/apache2/mod_socache_redis.so
@@ -109,7 +109,7 @@
 #LoadModule substitute_module libexec/apache2/mod_substitute.so
 #LoadModule sed_module libexec/apache2/mod_sed.so
 #LoadModule charset_lite_module libexec/apache2/mod_charset_lite.so
-#LoadModule deflate_module libexec/apache2/mod_deflate.so
+LoadModule deflate_module libexec/apache2/mod_deflate.so
 LoadModule mime_module libexec/apache2/mod_mime.so
 LoadModule log_config_module libexec/apache2/mod_log_config.so
 #LoadModule log_debug_module libexec/apache2/mod_log_debug.so
@@ -144,7 +144,7 @@
 #LoadModule session_dbd_module libexec/apache2/mod_session_dbd.so
 LoadModule slotmem_shm_module libexec/apache2/mod_slotmem_shm.so
 #LoadModule slotmem_plain_module libexec/apache2/mod_slotmem_plain.so
-#LoadModule ssl_module libexec/apache2/mod_ssl.so
+LoadModule ssl_module libexec/apache2/mod_ssl.so
 #LoadModule dialup_module libexec/apache2/mod_dialup.so
 #LoadModule http2_module libexec/apache2/mod_http2.so
 #LoadModule lbmethod_byrequests_module libexec/apache2/mod_lbmethod_byrequests.so
@@ -168,7 +168,7 @@
 </IfModule>
 #LoadModule dav_fs_module libexec/apache2/mod_dav_fs.so
 #LoadModule dav_lock_module libexec/apache2/mod_dav_lock.so
-#LoadModule vhost_alias_module libexec/apache2/mod_vhost_alias.so
+LoadModule vhost_alias_module libexec/apache2/mod_vhost_alias.so
 LoadModule negotiation_module libexec/apache2/mod_negotiation.so
 LoadModule dir_module libexec/apache2/mod_dir.so
 #LoadModule imagemap_module libexec/apache2/mod_imagemap.so
@@ -176,7 +176,7 @@
 #LoadModule speling_module libexec/apache2/mod_speling.so
 LoadModule userdir_module libexec/apache2/mod_userdir.so
 LoadModule alias_module libexec/apache2/mod_alias.so
-#LoadModule rewrite_module libexec/apache2/mod_rewrite.so
+LoadModule rewrite_module libexec/apache2/mod_rewrite.so
 
 <IfModule unixd_module>
 #
@@ -242,8 +242,10 @@
 # documents. By default, all requests are taken from this directory, but
 # symbolic links and aliases may be used to point to other locations.
 #
-DocumentRoot "/data/data/com.termux/files/usr/share/apache2/default-site/htdocs"
-<Directory "/data/data/com.termux/files/usr/share/apache2/default-site/htdocs">
+#DocumentRoot "/data/data/com.termux/files/usr/share/apache2/default-site/htdocs"
+DocumentRoot "/data/data/com.termux/files/home/htdocs"
+#<Directory "/data/data/com.termux/files/usr/share/apache2/default-site/htdocs">
+<Directory "/data/data/com.termux/files/home/htdocs">
     #
     # Possible values for the Options directive are "None", "All",
     # or any combination of:
@@ -256,14 +258,14 @@
     # http://httpd.apache.org/docs/2.4/mod/core.html#options
     # for more information.
     #
-    Options Indexes FollowSymLinks
+    Options FollowSymLinks
 
     #
     # AllowOverride controls what directives may be placed in .htaccess files.
     # It can be "All", "None", or any combination of the keywords:
     #   AllowOverride FileInfo AuthConfig Limit
     #
-    AllowOverride None
+    AllowOverride All
 
     #
     # Controls who can get stuff from this server.
@@ -276,7 +278,7 @@
 # is requested.
 #
 <IfModule dir_module>
-    DirectoryIndex index.html
+    DirectoryIndex index.php index.html
 </IfModule>
 
 #
@@ -529,3 +531,22 @@
 SSLRandomSeed connect builtin
 </IfModule>
 
+LoadModule php7_module libexec/apache2/libphp7.so
+<FilesMatch \.php
gt;
 +   SetHandler application/x-httpd-php
 +</FilesMatch>
 +<IfModule dir_module>
 +    DirectoryIndex index.php
 +</IfModule>
 +
 +<IfModule mod_deflate.c>
 +    DeflateCompressionLevel 1
 +    <IfModule mod_filter.c>
 +        FilterDeclare COMPRESS
 +        FilterProvider COMPRESS DEFLATE "%{CONTENT_TYPE} =~ m#^text/#i"
 +        FilterProvider COMPRESS DEFLATE "%{CONTENT_TYPE} =~ m#^application/(atom\+xml|javascript|json|rss\+xml|xml|xhtml\+xml)#i"
 +        FilterProvider COMPRESS DEFLATE "%{CONTENT_TYPE} =~ m#^image/(svg\+xml|vnd\.microsoft\.icon)#i"
 +        FilterChain COMPRESS
 +        FilterProtocol COMPRESS DEFLATE change=yes;byteranges=no
 +    </IfModule>
 +</IfModule>

パッチの適用は上記をコピペしてp.txt などに保存、httpd.conf に以下のように patchしてください。

$ patch -u httpd.conf < p.txt

成功すれば、patching file httpd.conf のような表示となります。

mariadb のチューニングとかはやってないです。PHPは、php.ini  に以下のように記載してあります。

$ cat /data/data/com.termux/files/usr/lib/php.ini
[PHP]

upload_max_filesize = 64M
post_max_size = 64M
memory_limit = 64M

結構、スマホでも動くなー、いけそうだなーっていう感じです。

Rapid START CDNは諦めてJetpackプラグインのWordPressが提供しているCDNを使ってどうなるか検討してみる

結局、Rapid START CDNは登録したけどもうまく反映できず、諦めました。手順通りにやっても、CNAMEを切り替え後に Error 503 Backend Error になるんですよね。結局、フェイスブックの問い合わせにもお返事がなかったので原因を追求することが難しくなりました。

 ということで、CDNはとりあえず諦めようかなと思いますが、Jetpack をまだ入れて試していませんでした。Jetpackには、ワードプレスが提供しているCDNが使えるようになります。説明は以下にあります。

Site Accelerator

JetpackのSite Acceleratorは、Jetpackが画像を最適化し、サーバーのグローバルネットワークから画像と静的ファイル(CSSやJavaScriptなど)を提供できるようにすることで、ページの読み込みを高速化します。

あと、Jetpackを入れるメリットとしては、WordPressのローカルアプリで、Macから投稿するときのブログ投稿ツールが使えるようになります。最近はこれを使っていたので、今後もこれを使おうとする場合は、Jetpackを入れないとだめなようです。

まぁ、違う投稿ツールを使えばいいんですが、慣れているんでこっちで出来れば良いかなと。CDNも使えるしね。

以前検討した時は、Jetpackを入れると遅くなるっていうことがわかり外しましたが、あれはネット回線もサーバマシンも高速であったため、CDN使わなくても速かったからです。今度は、スマホサーバで動かしているし、回線もIPv4を使っているので、以前より速くありません。ちなみに、今はInterLink の PPoEのIP1固定を検討中で使っています。これは逆引きドメインを設定できるので良いなーと。またそれは別に紹介するとします。

 ではJetpackを入れてみましょう。しかし、ClassicPressでは動作しないので、WordPress最新を入れる必要があります。面倒ですが入れ直して、Jetpackプラグイン設定。一応、同条件で計測しておきました。

・Jetpackを入れる前のWordPress

・Jetpackを導入直後のWordPress

囲ってある部分が、Jetpackで変化があった部分ですが、レンダリング開始秒までは、Jetpack使用後もさほど代わりがありません。まだこの時は、最初のindex相当の部分は、CDN上ではないようです。JetpackでCDNになるのは、WordPress 共通で使うjquery.jsだったりの部分です。
※追記 ファーストアクセスの部分(上記でいえば、index相当の部分)は仕組み上CDNからのアクセスにはならないと思います。

設定はこのようにしています。もうちょっと様子見してみますか。あー、なんで画像が計測結果に出てないかわかりました!

上記2つの計測結果には、画像がまだエリア内に表示されていないので表示されなかったみたいです。

違うページを計測してみたら、以下のように画像URLが変わっていました。

https://i0.wp.com/jh.gpl.jp/wp-content/uploads/2020/08/e8b2bce3828ae4bb98e38191e3819fe794bbe5838f_2020_08_24_1_04.png?resize=496%2C1080

あーなるほどね。とりあえず、Jetpack入れて様子見してみます。

WPのcdnから配信された画像データと、オリジナルのファイルサイズを比較してみると以下のように半分くらいになっています。

$ ll
::
-rw-r--r--@  1 junkhack  staff  776994  9  5 21:20 org.png
-rw-r--r--@  1 junkhack  staff  281594  9  5 21:19 wpcdn.png

綺麗な画像で見せたい場合は、CDNから配信しないのがいいですね。ここで見せる画像なんかは、特にこだわりはないので問題ありませんが。

備忘録:macosの静的ルートの追加

いつも忘れてしまうので、メモしておくことに。Linuxとは、少し違い永続的な設定方法は専用コマンドがあります。networksetup コマンドです。

・ネットワークデバイス名の一覧

$ networksetup -listallnetworkservices
An asterisk (*) denotes that a network service is disabled.
Built-in Serial Port (1)
Ethernet
iPhone USB
Wi-Fi
Bluetooth PAN

・ネットワークデバイスの情報

$ networksetup -getinfo Ethernet
DHCP Configuration
IP address: 192.168.1.26
Subnet mask: 255.255.255.0
Router: 192.168.1.1
Client ID: 
IPv6: Automatic
IPv6 IP address: none
IPv6 Router: none
Ethernet Address: 90:2b:34:d0:02:80

・静的経路の追加と削除

永続的に追加。この例では、124.41.83.243/32 あては、192.168.1.38 へ送ります。

$ sudo networksetup -setadditionalroutes Ethernet 124.41.83.243 255.255.255.255 192.168.1.38

削除。何もパラメータに設定しないと消えます。

$ sudo networksetup -setadditionalroutes Ethernet
There are no additional IPv4 routes on Ethernet.

再起動すると消えますが一時的に設定したい場合

sudo route -n add 124.41.83.243/32 192.168.1.38

削除は

sudo route -n delete 124.41.83.243/32

・確認

$ networksetup -getadditionalroutes Ethernet
124.41.83.243 255.255.255.255 192.168.1.38

または、

$ netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            192.168.1.1        UGSc           67        5     en0
124.41.83.243      192.168.1.38       UGHS            0        0     en0
::

Termuxのapache2+php+mariadbのチューニング前のwordpressの速度とか

さて、今回はメモ程度ですが スマホUMIDIGI F2に、termuxでapache2とphp7とmariadb10を入れた環境にWordPress代替えのClassicPressを入れて動作させてみました。いろいろ課題が見えて来たのでメモしておきます。まずは、どのくらいの速度で表示されるか、視覚的に見ると以下になります。約1.8秒です。

WebPageTest_-_Visual_Comparison_-_Aug_31__2020___jh_gpl_jp_

 

これは、後ほど出て来ますが https://www.webpagetest.org/ でのテスト結果です。ちょっと遅いですよね。まぁ、しかしスマホで動作していると思えば十分に速いかもしれません。

まだ設定は未調整ですがhttp接続(SSLじゃない80接続)でのベンチマークです。コマンドラインでのapache ab テストもやってみました。同時に100ユーザが、1ユーザーあたり10リクエストを発行した場合を想定しています。これは、一般的なhtmlアクセスに対するjsやcssや画像のアクセスかなと思います。まぁ、このブログはそんな人気じゃないので同時に10人くらいのアクセスで十分かもですがw

サーバ側の状態は、ClassicPressをデフォルトで入れた状態です。テーマは、ClassicPressのTwentySixteenです。画像は出ない状態で全部テキストです。htmlやcssやjsやfontなど全部で、278 KBです。

まず、ローカルのリモート(macos)から。

$ ab -n 1000 -c 100 http://192.168.1.38:8080/

Server Software:        Apache/2.4.46
Server Hostname:        192.168.1.38
Server Port:            8080

Document Path:          /
Document Length:        15825 bytes

Concurrency Level:      100
Time taken for tests:   78.390 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      16123000 bytes
HTML transferred:       15825000 bytes
Requests per second:    12.76 [#/sec] (mean)
Time per request:       7839.037 [ms] (mean)
Time per request:       78.390 [ms] (mean, across all concurrent requests)
Transfer rate:          200.86 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    4  15.5      1     410
Processing:   490 7663 5599.2   6405   30174
Waiting:      461 7317 5486.8   5962   30109
Total:        494 7667 5599.1   6407   30175

Percentage of the requests served within a certain time (ms)
  50%   6407
  66%   7733
  75%   9622
  80%  10952
  90%  16804
  95%  19520
  98%  24822
  99%  26571
 100%  30175 (longest request)

次は、GCPの東京リージョンからです。この経路は80←→8080にポート転送していますが、その差は感じない程度ですね。termux は、80ポートや443ポートでは運用できない制限がありますので、ルータで変換します。

$ ab -n 1000 -c 100 http://jh.gpl.jp/

Server Software: Apache/2.4.46
Server Hostname: jh.gpl.jp
Server Port: 80

Document Path: /
Document Length: 15742 bytes

Concurrency Level: 100
Time taken for tests: 78.813 seconds
Complete requests: 1000
Failed requests: 0
Total transferred: 16040000 bytes
HTML transferred: 15742000 bytes
Requests per second: 12.69 [#/sec] (mean)
Time per request: 7881.291 [ms] (mean)
Time per request: 78.813 [ms] (mean, across all concurrent requests)
Transfer rate: 198.75 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 21 190 525.8 51 3058
Processing: 707 7470 4143.1 7264 22358
Waiting: 605 7100 4070.2 6790 22218
Total: 804 7661 4221.0 7341 22409

Percentage of the requests served within a certain time (ms)
50% 7341
66% 8008
75% 8490
80% 9059
90% 14244
95% 16246
98% 20310
99% 21250
100% 22409 (longest request)

次はtermuxが動作しているローカルからです。

$ ab -n 1000 -c 100 http://192.168.1.38:8080/

Server Software: Apache/2.4.46
Server Hostname: 192.168.1.38
Server Port: 8080

Document Path: /
Document Length: 15825 bytes

Concurrency Level: 100
Time taken for tests: 77.274 seconds
Complete requests: 1000
Failed requests: 0
Total transferred: 16123000 bytes
HTML transferred: 15825000 bytes
Requests per second: 12.94 [#/sec] (mean)
Time per request: 7727.448 [ms] (mean)
Time per request: 77.274 [ms] (mean, across all concurrent requests)
Transfer rate: 203.76 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 1428 791.4 1531 3535
Processing: 562 6046 2311.5 5785 16840
Waiting: 515 4357 2249.9 3816 16085
Total: 649 7474 2189.4 7356 17166

Percentage of the requests served within a certain time (ms)
50% 7356
66% 8082
75% 8376
80% 8620
90% 9861
95% 11707
98% 12754
99% 13209
100% 17166 (longest request)

ちなみに、ローカルのリモート(macos)からしか試していませんが、スマホの接続をWiFi接続を5Ghzではなく、2.4Ghzで接続した場合は以下でした。これ有線だとどうなるんでしょうかね。type-c と有線イーサネットは1つありますが、繋げても接続できなかったのでまだテストしていません。

Server Software: Apache/2.4.46
Server Hostname: 192.168.1.38
Server Port: 8080

Document Path: /
Document Length: 15825 bytes

Concurrency Level: 100
Time taken for tests: 84.280 seconds
Complete requests: 1000
Failed requests: 0
Total transferred: 16123000 bytes
HTML transferred: 15825000 bytes
Requests per second: 11.87 [#/sec] (mean)
Time per request: 8427.984 [ms] (mean)
Time per request: 84.280 [ms] (mean, across all concurrent requests)
Transfer rate: 186.82 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 11 13.3 5 135
Processing: 491 7692 4699.6 7107 25513
Waiting: 443 7301 4611.2 6657 25511
Total: 493 7703 4700.0 7139 25514

Percentage of the requests served within a certain time (ms)
50% 7139
66% 8172
75% 9108
80% 10369
90% 14578
95% 18137
98% 20897
99% 22101
100% 25514 (longest request)

多少、劣るようですがそこまで気にしなくてもいいかもです。

それよりも、最初のhtmlのロードが長いです。以下は一番最初のビデオの状態を詳細にみた結果です。まだ圧縮転送やキャッシュは効かせていませんが、マシン性能が出る部分ですかね。ちょっと遅いです。NGINXだともう少し速くなるかもですので、また試してみたいと思います。

貼り付けた画像_2020_08_31_1_41

このWEBページのindex相当になるファイルはサイズ、15kb程度です。例えば、phpinfoのページを読んだ結果は以下です。このページは、82.0 KBありますが、0.4秒で終わっています。

WebPageTest_Test_Details_-_Tokyo___jh_gpl_jp_info_php_-_08_31_20_01_45_34

つまり、mariadbにアクセスしたりphpでのwordpressの処理時間がかかっているから遅くなっているということになりますね。

例えば、これは以前検討していたマシンでの結果ですが、htmlのロードは0.2秒以内に終わっています。UnixBenchが7000近く出るマシンでネットワークもIPv4→IPv6トンネルなので、比較するとあれですが、どこまで近づけるかですね。

WebPageTest_Test_Details_-_Tokyo___hoge_gpl_jp_-_03_16_20_02_24_59

まぁ、速度的なことより困っていることがあります。それは、ローカルのマシンから、termux上で動作しているwordpressにグローバルIPでアクセスできないことです。この場合、ルータの管理画面にアクセスしちゃうんで、どうしようかなと。こういうのなんていうんでしたっけか? とにかく、今の拠点のルータ(PR-400KI)は、内側ネットワークから外側のグローバルアドレスにアクセスしたものを、変換(最終的にサーバのプライベートアドレスに変換)してくれないのです。

プライベートアドレスだと、wordpressの設定で、グローバルのIPがマッピングされているドメイン名の設定になっているので(ルータで80と8080をポート転送してwordpressを運用)、リダイレクトされてアクセスできないんですよね。これはwordpress の仕様みたいなので回避不可能かなと。なんか言葉で書くとわかりにくいですね。今度、時間があるときに図解で問題点を明確にしたいです。

今の所、2案あります。1つは、マルチセッションを貼って違う光プロバイダーからアクセスさせる方法。もう一つは、リバースプロキシを経由させる方法です。

スマホで非ルートで動かすtermux は、IPテーブルとかルーティングとかいじれないので工夫が必要ですね。

ネットワークはあんまり得意じゃないんで、もっといい解決方法があるかもしれませんが。

衝撃価格7500円でゲットしたRedmi Note 9SにLinux入れてUnixBenchを計測

いやー、もう8月も終わりに近づてきましたね〜!
皆さんはどっか行きましたか? 自分はお盆休みもバイクをモリワキカラーに塗っていましたよ。どこにも行ってないので、そろそろプチ旅行したいです。バイクに乗りたいですね。

さて、今回はOCNモバイルONEの乗り換えキャンペーンで激安7500円で新品本体をゲットしましたRedmi Note 9S にUnixBechを走らせてみたいと思います。
AndroidスマホなのにLinux上で走るUnixBenchをどうやって動かすってことですが、これは、TermuxというAndroidターミナルエミュレーター+Linux環境構築アプリがあります。この環境で、UnixBenchをビルドしてスコアを計測してみました。antutuは28万くらいらしいのですが、UnixBenchはどのくらい出るでしょうか。ちなみに、UmidigiF2は、前回

シングルCPU・・・スコア406.2
8CPU・・・・・・スコア1312.3

のスコアが出ました。
まだシステムのアップデートする前なんで、少しkernelバージョンは変わるかもしれませんが、計測時のスマホの状態を貼っておきます。Redmi Note 9Sは、CPUがUmidigiF2よりも速いので、1500くらいのスコアが出るかもなーと思っていますが、さてどのくらいになるでしょうか?

貼り付けた画像_2020_08_28_22_39

まぁ、前置きが長かったのですが、やってることは大したことはないです。まずはGoogleStoreから、以下のアプリを入れておきます。これなんて読むんですかね? たーむゆーえっくす とか、たーむっくす とかかな?

Termux_-_Google_Play_のアプリ

openssh を入れてリモートから作業します。スマホ画面では、最低限以下を入れて起動しておきます。

pkg install openssh -y && sshd

WiFi アドレスを確認しておきます。

ip a | more
または、
ip a | grep inet | grep wlan
もっとズバリIPだけ取り出したい場合は、
ip -4 a | grep inet | grep wlan0 | grep -oP ‘[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+(?=\/)’

鍵作るなり、パスワード設定するなりしてリモートからログインします。今回は、passwd してパスワード認証でリモートログイン。

ssh 192.168.xxx.xxx -p 8022

デフォルトsshポートは、8022 です。では、UnixBenchのビルドに必要なツールを入れましょう。

pkg install vim wget clang make perl git pkg-config -y

あとは前回と同様、Makefileを少し修正して ./Run です。

git clone https://github.com/kdlucas/byte-unixbench
cd byte-unixbench/UnixBench
cp -p Makefile Makefile.org
vi Makefile
※以下部分を削除してね。(-march=native)

$ diff -u Makefile.org Makefile
--- Makefile.org	2020-08-28 23:39:45.550203419 +0900
+++ Makefile	2020-08-28 23:40:56.800203392 +0900
@@ -95,7 +95,7 @@
     #   - Supported    : x86, x86_64, ARM, AARCH64, etc..
     #   - Not Supported: RISC-V, IBM Power, etc...
     ifneq ($(ARCH),$(filter $(ARCH),ppc64 ppc64le))
-        OPTON += -march=native -mtune=native
+        OPTON += -mtune=native
     else
         OPTON += -mcpu=native -mtune=native
     endif

./Run
::

金曜の夜は眠いです、、、寝そうになりましたがベンチマークが終わったので貼り付け。

CPU:Qualcomm Snapdragon 720G
Hardware : Qualcomm Technologies, Inc SM7125

========================================================================
   BYTE UNIX Benchmarks (Version 5.1.3)

   System: localhost: Android
   OS: Android -- 4.14.117-perf-g2d34faf -- #1 SMP PREEMPT Wed May 13 01:02:15 CST 2020
   Machine: aarch64 (unknown)
   Language: en_US.utf8 (charmap=, collate=)
   23:41:17 up 12:11,  load average: 0.00, 0.00, 0.00; runlevel 

------------------------------------------------------------------------
Benchmark Run: Fri Aug 28 2020 23:41:17 - 00:09:22
8 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables       32061907.1 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     6143.9 MWIPS (10.0 s, 7 samples)
Execl Throughput                                267.0 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        630326.5 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks          205587.3 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks       1214283.1 KBps  (30.0 s, 2 samples)
Pipe Throughput                             1227952.4 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 105358.2 lps   (10.0 s, 7 samples)
Process Creation                                594.4 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   1306.7 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                    311.0 lpm   (60.1 s, 2 samples)
System Call Overhead                        1131049.8 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   32061907.1   2747.4
Double-Precision Whetstone                       55.0       6143.9   1117.1
Execl Throughput                                 43.0        267.0     62.1
File Copy 1024 bufsize 2000 maxblocks          3960.0     630326.5   1591.7
File Copy 256 bufsize 500 maxblocks            1655.0     205587.3   1242.2
File Copy 4096 bufsize 8000 maxblocks          5800.0    1214283.1   2093.6
Pipe Throughput                               12440.0    1227952.4    987.1
Pipe-based Context Switching                   4000.0     105358.2    263.4
Process Creation                                126.0        594.4     47.2
Shell Scripts (1 concurrent)                     42.4       1306.7    308.2
Shell Scripts (8 concurrent)                      6.0        311.0    518.3
System Call Overhead                          15000.0    1131049.8    754.0
                                                                   ========
System Benchmarks Index Score                                         569.6

------------------------------------------------------------------------
Benchmark Run: Sat Aug 29 2020 00:09:22 - 00:37:59
8 CPUs in system; running 8 parallel copies of tests

Dhrystone 2 using register variables      120620219.0 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                    26336.2 MWIPS (9.5 s, 7 samples)
Execl Throughput                               1110.7 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        588338.4 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks          181982.1 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks       1457866.0 KBps  (30.0 s, 2 samples)
Pipe Throughput                             4512922.8 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 160612.9 lps   (10.0 s, 7 samples)
Process Creation                                947.0 lps   (30.1 s, 2 samples)
Shell Scripts (1 concurrent)                   2990.6 lpm   (60.1 s, 2 samples)
Shell Scripts (8 concurrent)                    399.8 lpm   (60.5 s, 2 samples)
System Call Overhead                        3946715.9 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0  120620219.0  10335.9
Double-Precision Whetstone                       55.0      26336.2   4788.4
Execl Throughput                                 43.0       1110.7    258.3
File Copy 1024 bufsize 2000 maxblocks          3960.0     588338.4   1485.7
File Copy 256 bufsize 500 maxblocks            1655.0     181982.1   1099.6
File Copy 4096 bufsize 8000 maxblocks          5800.0    1457866.0   2513.6
Pipe Throughput                               12440.0    4512922.8   3627.8
Pipe-based Context Switching                   4000.0     160612.9    401.5
Process Creation                                126.0        947.0     75.2
Shell Scripts (1 concurrent)                     42.4       2990.6    705.3
Shell Scripts (8 concurrent)                      6.0        399.8    666.3
System Call Overhead                          15000.0    3946715.9   2631.1
                                                                   ========
System Benchmarks Index Score                                        1177.5

シングル性能では、UmidigiF2より上ですが、マルチCPUは下ですね。

シングルCPU・・・スコア569.6
8CPU・・・・・・スコア1177.5

特に、プロセスのフォーク処理(Process Creation)とか、シェル関連とか、パイプ処理(Pipe-based Context Switching)が半分くらい遅いですね。なんでこんなに遅いのでしょうか? システムバージョンアップして、また計測してみます。

貼り付けた画像_2020_08_29_0_57

再起動後の情報です。

貼り付けた画像_2020_08_29_1_06

Kernelの末尾の番号だけ微妙に変わっていますが、メジャー・マイナー・メンテナンスの番号は変わらずですね。4.14.117です。UmidigiF2は、4.14.141+で新しいですね。

結果が出たら貼り付けておきます。今日はもうねるー! UmidigiF2 のCPU、MediaTek Helio P70もなかなか良いのかもね。

追記。翌日ベンチマークが終わっていたので貼り付けておきます。誤差の範囲でほぼ同じ結果でした。今回もやはり、プロセスのフォーク処理(Process Creation)とか、シェル関連とか、パイプ処理(Pipe-based Context Switching)がUmidigiF2と比べて半分くらい遅い結果となりました。何かKernelかOS設定で制限があるのかもですね。ファイルコピーなんかは倍くらいRedmeNote9sが速いですが。

CPUやストレージが速ければ全部のスコアが上がるというわけはないということですね。

シングルCPU・・・スコア571.9
8CPU・・・・・・スコア1127.1

ちなみに、UnixBenchのパイプ処理に使うバイナリのヘッダ情報も乗せておきます。ちゃんと64bitでビルドされていますね。Termux、なかなかいいんじゃないでしょうか。

$ readelf -h ./spawn
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2’s complement, little endian
Version: 1 (current)
OS/ABI: UNIX – System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: AArch64
Version: 0x1
Entry point address: 0x760
Start of program headers: 64 (bytes into file)
Start of section headers: 7184 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 8
Size of section headers: 64 (bytes)
Number of section headers: 24
Section header string table index: 23

ということで、次回はUmidigiF2にWordPressが動く環境を作ってテストしてみたいですね。

   BYTE UNIX Benchmarks (Version 5.1.3)

   System: localhost: Android
   OS: Android -- 4.14.117-perf-g638d6a0 -- #1 SMP PREEMPT Fri Jun 19 01:24:32 CST 2020
   Machine: aarch64 (unknown)
   Language: en_US.utf8 (charmap=, collate=)
   01:18:25 up 17 min,  load average: 0.55, 1.10, 1.44; runlevel 

------------------------------------------------------------------------
Benchmark Run: Sat Aug 29 2020 01:18:25 - 01:46:30
8 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables       32007008.4 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     6140.3 MWIPS (10.0 s, 7 samples)
Execl Throughput                                261.7 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        628988.7 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks          207751.6 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks       1478525.0 KBps  (30.0 s, 2 samples)
Pipe Throughput                             1164727.3 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  99925.0 lps   (10.0 s, 7 samples)
Process Creation                                587.5 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   1284.4 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                    312.1 lpm   (60.2 s, 2 samples)
System Call Overhead                        1127699.3 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   32007008.4   2742.7
Double-Precision Whetstone                       55.0       6140.3   1116.4
Execl Throughput                                 43.0        261.7     60.9
File Copy 1024 bufsize 2000 maxblocks          3960.0     628988.7   1588.4
File Copy 256 bufsize 500 maxblocks            1655.0     207751.6   1255.3
File Copy 4096 bufsize 8000 maxblocks          5800.0    1478525.0   2549.2
Pipe Throughput                               12440.0    1164727.3    936.3
Pipe-based Context Switching                   4000.0      99925.0    249.8
Process Creation                                126.0        587.5     46.6
Shell Scripts (1 concurrent)                     42.4       1284.4    302.9
Shell Scripts (8 concurrent)                      6.0        312.1    520.1
System Call Overhead                          15000.0    1127699.3    751.8
                                                                   ========
System Benchmarks Index Score                                         571.9

------------------------------------------------------------------------
Benchmark Run: Sat Aug 29 2020 01:46:30 - 02:15:04
8 CPUs in system; running 8 parallel copies of tests

Dhrystone 2 using register variables      122466899.1 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                    26082.3 MWIPS (9.9 s, 7 samples)
Execl Throughput                               1100.0 lps   (29.7 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        509969.0 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks          147009.9 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks       1308075.6 KBps  (30.0 s, 2 samples)
Pipe Throughput                             4401030.7 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 163599.9 lps   (10.0 s, 7 samples)
Process Creation                               1059.8 lps   (30.1 s, 2 samples)
Shell Scripts (1 concurrent)                   2761.2 lpm   (60.1 s, 2 samples)
Shell Scripts (8 concurrent)                    366.4 lpm   (60.8 s, 2 samples)
System Call Overhead                        3964160.3 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0  122466899.1  10494.2
Double-Precision Whetstone                       55.0      26082.3   4742.2
Execl Throughput                                 43.0       1100.0    255.8
File Copy 1024 bufsize 2000 maxblocks          3960.0     509969.0   1287.8
File Copy 256 bufsize 500 maxblocks            1655.0     147009.9    888.3
File Copy 4096 bufsize 8000 maxblocks          5800.0    1308075.6   2255.3
Pipe Throughput                               12440.0    4401030.7   3537.8
Pipe-based Context Switching                   4000.0     163599.9    409.0
Process Creation                                126.0       1059.8     84.1
Shell Scripts (1 concurrent)                     42.4       2761.2    651.2
Shell Scripts (8 concurrent)                      6.0        366.4    610.7
System Call Overhead                          15000.0    3964160.3   2642.8
                                                                   ========
System Benchmarks Index Score                                        1127.1