カテゴリー: WordPress

投稿日: 更新日:2020年9月7日 Linux, osx, WordPress

ポートフォワードの経路で、Uターン NATとかヘアピンNATが使えないルータの場合のあれこれ

先日、以下のように困っていました。

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

これ、言葉で書くとよくわかりませんが、どんな問題かというと以下のようになります。

こういう表現として、UターンNATとか、ヘアピンNATとか呼ぶようです。これが出来るルータとできないルータがあり、NTTから借りているルータではできませんでした。いろいろ解決方法があるとは思いますが、一番簡単なのは、クライアントPCをVPNで外部のネットワークからアクセスさせる方法です。つくば大学のVPN Gateを使えば簡単に解決できますが、インターネット経路となりいまいちです。プレイベート間の通信なのでリバースプロキシを経由する方法が良さそうです。ポート変換がなければ、hosts を書き換えるか、内部DNSを立ち上げればいいのですが、今回の場合は、スマホサーバで提供しているポートは8080です。80と8080を対応付ける必要があり、hosts だけでは無理なので、リバースプロキシを通して、アクセスしてみることにします。

　ブログの更新は、クライアントPCからしか行わないのでこのPC中に設置してみました。もちろんリバースプロキシを分離して、内部DNSを立ち上げれば、理論上は何台でも違うポートとIPを使って好きなドメインでアクセスできます。そのうち、IoTデバイスとか、スマホサーバでクラスタリングとかロードバランサーとか使い出したら内部DNSやリバースプロキシは欲しくなってくるのですが、それはその時にまた考えることにします。

　ということで、クライアントにリバースプロキシを作って、スマホサーバの8080ポートで提供されているWordPress にアクセスしてみることにします。幸い、クライアントはMacなので nginx とかで簡単に作れます。

Macでリバースプロキシをnginxで作る

経路のイメージはこんな感じでしょうか。まずは、nginx を入れます。

$ brew install nginx

起動と再起動、停止は以下のようにします。

・起動
$ sudo nginx
・再起動
$ sudo nginx -s reload
・停止
$ sudo nginx -s stop

設定を以下のように書き換えます。server_nameや、proxy_passのIPやポートなど読み替えて書き換えてみてください。

/usr/local/etc/nginx/nginx.conf
::
worker_processes 1;
error_log /usr/local/var/log/nginx/error.log;

events {
  worker_connections  1024;
}

http {
  # This should be in the same directory as this conf
  # e.g. /usr/local/etc/nginx
  include       mime.types;
  default_type  application/octet-stream;
  
  # Note this log_format is named 'main', and is used with the access log below
  log_format   main '$remote_addr - $remote_user [$time_local]  $status '
    '"$request" $body_bytes_sent "$http_referer" '
    '"$http_user_agent" "$http_x_forwarded_for"';

  sendfile        on;
  keepalive_timeout  65;

  # Without this I got this error: 'upstream sent too big header
  # while reading response header from upstream'
  proxy_buffer_size   128k;
  proxy_buffers   4 256k;
  proxy_busy_buffers_size   256k;

  server {
      listen 80;
      server_name jh.gpl.jp;
      proxy_set_header    Host    $host;
      proxy_set_header    X-Real-IP    $remote_addr;
      proxy_set_header    X-Forwarded-Host       $host;
      proxy_set_header    X-Forwarded-Server    $http_host;
      proxy_set_header    X-Forwarded-For    $proxy_add_x_forwarded_for;
      access_log /usr/local/var/log/nginx/reverse-proxy.access.log  main;

      location / {
          proxy_pass         http://192.168.1.38:8080;
      }
  }
}

hosts を書き換えます。

$ cat /etc/hosts
::
127.0.0.1 jh.gpl.jp

nginx を再起動して、ブラウザでドメインに対してアクセスすればOKです。

ちなみに、wp-config.php に以下を追記すると、接続元が192.168.1.26 の時だけWordPress のドメイン名が www.gpl.jp に書き換わります。もちろん、アクセスするクライアントのhosts は書き換える必要があります。

if( $_SERVER['REMOTE_ADDR'] == '192.168.1.26' ){
    define('WP_HOME','http://www.gpl.jp');
    define('WP_SITEURL','http://www.gpl.jp');
}

ということで、macos で簡単にリバースプロキシーを立ち上げて、内部ネットワークの違うポートで提供されているWordPress にアクセスする方法でした。

Lan内部のスマホからもアクセスしたい場合は、内部DNSをDHCPで配布して、リバースプロキシーと対応付けしないとだめですので、完璧を求めるならそれらが必要です。そのうち、作る機会があれば紹介したいなと思います。

投稿日: 更新日:2021年6月2日 Blog, Linux, WordPress, 高速化

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

とりあえず、１つの指標としてメモしておくことにします。まず、改善結果から。データ量は、今見ているこのブログの過去記事、約４００件のデータでテンプレートは、Hew　です。TOPの表示記事数は３です。スマホ側は、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 の全ての機能を試していませんが、とりあえずは動いている感じです。設定も以下のように単純です。手動でのキャッシュ削除は設定画面の２箇所から可能です。

シンプルキャッシュ‹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

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

投稿日: 更新日:2020年9月3日 cdn, ClassicPress, WordPress

Rapid START CDNを試す！　が、ハマりどころいっぱい！

Rapid START CDNっていう国産のCDNがあって前から試してみたかったんですが、今回良い機会なので実際に登録してみました。

まず結論から行くとまだうまく行っていません。ハマりどころがあるんで、まずそれを記録しておくことにします。きっと、誰かの役にたつかもです。

ハマりどころ１

サブドメインで、一文字は登録できません。例えば、以下のようなサブドメインは、登録しようとするとエラーが出ます。

j.gpl.jp

２文字以上はOKです。１文字はサブドメインとしては問題なくちゃんとアクセスも出来るし通常のDNSにも登録できます。Rapid START CDN側の問題というか制約でしょう。

汎用JPドメインの第２レベルは、３文字以上しか登録できませんが、第３レベル（今回でいうjの部分）はドメイン運用者が自由に決めらます。文字種は限りがあります。英字(A～Z)、数字(0～9)、 ハイフン( – )が使用できます(先頭と末尾の文字をハイフンとするのは不可)

では、２文字でやって見ましょう。Good Gameの略でgg.gpl.jpということにしましょうか。Gが多すぎて見にくいですがね。まぁテストなんで良しとしましょう。DNS登録して、digなどで引いてみましょう。TTLは60秒と短くしてあります。

# dig gg.gpl.jp
::
;; ANSWER SECTION:
gg.gpl.jp. 60 IN A 116.58.181.140
::

では、RapidStartのCDNコンパネで登録してみましょう。

はい、できました！次は、オリジンサーバのAレコードをDNSに登録します。
origin.gg.gpl.jp
というAレコードです。こんな感じで引ければOKです。

# dig origin.gg.gpl.jp
::
;; ANSWER SECTION:
origin.gg.gpl.jp.	60	IN	A	116.58.181.140
::

次はドメイン所有確認のため、長いドメイン部のテキストレコードをDNSに設定しておきます。

以下のように確認しておきます。

$ dig -t TXT xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.jh.gpl.jp
::
;; ANSWER SECTION:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.jh.gpl.jp. 60 IN TXT "redbox-cdn-verification=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
::

所有確認が出来れば、ステータスがOKになります。コンパネの設定から、WordPress のキャッシュポリシーにしておきます。

あとは、動作確認のためhostsファイルを書き換えて確認せよとありますのでやってみます。

$ cat /etc/hosts
#::
127.0.0.1	localhost
255.255.255.255	broadcasthost
::1             localhost

160.16.92.179 gg.gpl.jp

これでブラウザーから　http://gg.gpl.jp/　へアクセスしてみます。

さて、何がだめなんでしょうかね？　どなたかわかる方いらっしゃいましたらコメントください。一応、RapidStartのフェイスブックのチャットで聞いているんですが、まだ回答がありません。

ちなみに、このテストがOKであれば、該当Aレコードをcnameに書き換えます。が、このままでは同じ結果になるのでCNAME書き換えてもだめです。

この　free.rs.cdnw.net のIPは引いてみると以下です。

$ dig free.rs.cdnw.net
::（略）
;; ANSWER SECTION:
free.rs.cdnw.net.	29	IN	A	59.106.219.219

59.106.219.219 なんですが、160.16.92.179　からでも同じホストへアクセスできるのでしょうかね。ちょっと相手側構成はわかりませんが、そのように指示があるので経路が違うだけなんでしょう。

一応、試したことは以下ですが、同じ結果です。

・コンパネからキャッシュの全削除
　→　上のほうに失敗の文字がでているんですが消せてるんでしょうかね。

・同じことをもう一度、違うサブドメインで登録
　→　最初、jh.gpl.jp で登録し、今回 gg.gpl.jp でやってみたがだめ。

投稿日: 更新日:2020年8月24日 Android, Blog, Linux, WordPress

AndroidスマホにCentOSとかUbuntuとか入れて活用できるか検討してみる

このブログの自宅サーバ化計画があるんですが、その候補マシンとして先日（といってもだいぶ前ですが）ThinkCentre M75q-1 Tinyを用意してあります。このマシン、かなり速くて自宅サーバ用途だけに使うのは勿体ないなーなんて思っています。実際、フォートナイト専用マシンとしてめっちゃ遊んでいます。Linuxを入れてもUnixBenchがスコアが6500を超える激速いマシンなんですよね。そこで、ダメ元でと思い最近スマホも変えたことですし、UmidigiF2にCentOSとかFedoraとか入れて使えないかなーって思ったわけです。

貼り付けた画像_2020_08_24_1_04

普通、AndroidスマホにLinuxを入れるにはrootを取得してオリジナルなOSをインストールするんですが、カスタムROMを作らないといけないのでメンテナンスが面倒なのとarmプラットフォームなんでマイナーなオープンソースソフトウェアはバイナリがないので、コンパイルしないとだめなんです。まぁ、くそメンドくさいので候補から外していたんですが、最近の事情はもっと気軽に入れられるようでした。上の画像のアプリ、UserLAndとか、Termuxとか、AnLinuxとかがそれです。UserLAndは、それ単体でディストリビューションが組み込めます。

貼り付けた画像_2020_08_24_1_09

この環境（UserLAndでUbuntu）で、計測したUnixBenchが以下です。スマートフォンはUmidigiF2です。CPUの型番や認識しているハードウェアは以下となります。

CPU MediaTek Helio P70
Hardware : MT6771V/CT

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

System: localhost: GNU/Linux
OS: GNU/Linux — 4.14.141+ — #1 SMP PREEMPT Wed May 6 10:13:36 CST 2020
Machine: aarch64 (aarch64)
Language: en_US.utf8 (charmap=”ANSI_X3.4-1968″, collate=”ANSI_X3.4-1968″)
; runlevel

————————————————————————
Benchmark Run: Sat Aug 22 2020 20:54:06 – 21:22:31
8 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables 17608983.7 lps (10.0 s, 7 samples)
Double-Precision Whetstone 2700.6 MWIPS (9.9 s, 7 samples)
Execl Throughput 277.4 lps (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 244507.6 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 71657.5 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 676812.1 KBps (30.0 s, 2 samples)
Pipe Throughput 375078.4 lps (10.0 s, 7 samples)
Pipe-based Context Switching 73081.8 lps (10.0 s, 7 samples)
Process Creation 1843.0 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 973.9 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 237.1 lpm (60.2 s, 2 samples)
System Call Overhead 21729.5 lps (10.0 s, 7 samples)

System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 17608983.7 1508.9
Double-Precision Whetstone 55.0 2700.6 491.0
Execl Throughput 43.0 277.4 64.5
File Copy 1024 bufsize 2000 maxblocks 3960.0 244507.6 617.4
File Copy 256 bufsize 500 maxblocks 1655.0 71657.5 433.0
File Copy 4096 bufsize 8000 maxblocks 5800.0 676812.1 1166.9
Pipe Throughput 12440.0 375078.4 301.5
Pipe-based Context Switching 4000.0 73081.8 182.7
Process Creation 126.0 1843.0 146.3
Shell Scripts (1 concurrent) 42.4 973.9 229.7
Shell Scripts (8 concurrent) 6.0 237.1 395.2
System Call Overhead 15000.0 21729.5 14.5
========
System Benchmarks Index Score 271.2

————————————————————————
Benchmark Run: Sat Aug 22 2020 21:22:31 – 21:51:31
8 CPUs in system; running 8 parallel copies of tests

Dhrystone 2 using register variables 99917960.5 lps (10.0 s, 7 samples)
Double-Precision Whetstone 17134.8 MWIPS (9.5 s, 7 samples)
Execl Throughput 636.2 lps (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 391896.0 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 109010.1 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 1128491.8 KBps (30.0 s, 2 samples)
Pipe Throughput 1996740.3 lps (10.0 s, 7 samples)
Pipe-based Context Switching 274427.3 lps (10.0 s, 7 samples)
Process Creation 5289.1 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 2014.1 lpm (60.3 s, 2 samples)
Shell Scripts (8 concurrent) 291.2 lpm (63.5 s, 2 samples)
System Call Overhead 27627.6 lps (10.1 s, 7 samples)

System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 99917960.5 8562.0
Double-Precision Whetstone 55.0 17134.8 3115.4
Execl Throughput 43.0 636.2 148.0
File Copy 1024 bufsize 2000 maxblocks 3960.0 391896.0 989.6
File Copy 256 bufsize 500 maxblocks 1655.0 109010.1 658.7
File Copy 4096 bufsize 8000 maxblocks 5800.0 1128491.8 1945.7
Pipe Throughput 12440.0 1996740.3 1605.1
Pipe-based Context Switching 4000.0 274427.3 686.1
Process Creation 126.0 5289.1 419.8
Shell Scripts (1 concurrent) 42.4 2014.1 475.0
Shell Scripts (8 concurrent) 6.0 291.2 485.3
System Call Overhead 15000.0 27627.6 18.4
========
System Benchmarks Index Score 680.3

やっぱりchrootしているので、ちょっとオーバーヘットがあるようですね。もっと速いはずなんですが、prootを使っているようなのでその影響でしょうか。prootっていうのは、FreeBSDのjailに似た感じだと思います。これは、ハイパーバイザや準仮想化マシンのようなセキュアなものとは仕組みが違います。

次、Termuxの場合は、以下のようになりました。動かしているスマホは先と同じUmidigiF2です。

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

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

$ diff Makefile Makefile.org
98c98
< OPTON += -mtune=native
—
> OPTON += -march=native -mtune=native

./Run
::

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

System: localhost: Android
OS: Android — 4.14.141+ — #1 SMP PREEMPT Wed May 6 10:13:36 CST 2020
Machine: aarch64 (unknown)
Language: en_US.utf8 (charmap=, collate=)
21:45:18 up 41 days, 12:17, load average: 26.55, 26.58, 26.57; runlevel

————————————————————————
Benchmark Run: Sun Aug 23 2020 21:45:18 – 22:13:35
8 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables 17334020.9 lps (10.0 s, 7 samples)
Double-Precision Whetstone 3658.8 MWIPS (9.9 s, 7 samples)
Execl Throughput 215.1 lps (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 323431.8 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 101368.1 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 845384.2 KBps (30.0 s, 2 samples)
Pipe Throughput 591377.9 lps (10.0 s, 7 samples)
Pipe-based Context Switching 89414.5 lps (10.0 s, 7 samples)
Process Creation 1326.4 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 861.2 lpm (60.1 s, 2 samples)
Shell Scripts (8 concurrent) 381.1 lpm (60.1 s, 2 samples)
System Call Overhead 582221.0 lps (10.0 s, 7 samples)

System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 17334020.9 1485.3
Double-Precision Whetstone 55.0 3658.8 665.2
Execl Throughput 43.0 215.1 50.0
File Copy 1024 bufsize 2000 maxblocks 3960.0 323431.8 816.7
File Copy 256 bufsize 500 maxblocks 1655.0 101368.1 612.5
File Copy 4096 bufsize 8000 maxblocks 5800.0 845384.2 1457.6
Pipe Throughput 12440.0 591377.9 475.4
Pipe-based Context Switching 4000.0 89414.5 223.5
Process Creation 126.0 1326.4 105.3
Shell Scripts (1 concurrent) 42.4 861.2 203.1
Shell Scripts (8 concurrent) 6.0 381.1 635.1
System Call Overhead 15000.0 582221.0 388.1
========
System Benchmarks Index Score 406.2

————————————————————————
Benchmark Run: Sun Aug 23 2020 22:13:35 – 22:42:10
8 CPUs in system; running 8 parallel copies of tests

Dhrystone 2 using register variables 92727287.0 lps (10.0 s, 7 samples)
Double-Precision Whetstone 23155.4 MWIPS (10.0 s, 7 samples)
Execl Throughput 1153.0 lps (29.7 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 392313.3 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 105373.2 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 1156407.9 KBps (30.0 s, 2 samples)
Pipe Throughput 3402929.3 lps (10.0 s, 7 samples)
Pipe-based Context Switching 316242.6 lps (10.0 s, 7 samples)
Process Creation 7783.9 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 4043.3 lpm (60.1 s, 2 samples)
Shell Scripts (8 concurrent) 518.0 lpm (60.4 s, 2 samples)
System Call Overhead 3153958.3 lps (10.0 s, 7 samples)

System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 92727287.0 7945.8
Double-Precision Whetstone 55.0 23155.4 4210.1
Execl Throughput 43.0 1153.0 268.2
File Copy 1024 bufsize 2000 maxblocks 3960.0 392313.3 990.7
File Copy 256 bufsize 500 maxblocks 1655.0 105373.2 636.7
File Copy 4096 bufsize 8000 maxblocks 5800.0 1156407.9 1993.8
Pipe Throughput 12440.0 3402929.3 2735.5
Pipe-based Context Switching 4000.0 316242.6 790.6
Process Creation 126.0 7783.9 617.8
Shell Scripts (1 concurrent) 42.4 4043.3 953.6
Shell Scripts (8 concurrent) 6.0 518.0 863.3
System Call Overhead 15000.0 3153958.3 2102.6
========
System Benchmarks Index Score 1312.3

倍までは行きませんが、こっちは結構速いようです。しかし、以下に書かれているようにファイルシステム構成が通常のLinuxとは違い、またlibcがBionicのようです。

Differences from Linux
https://wiki.termux.com/wiki/Differences_from_Linux

BionicなLibcとは、AndroidのCライブラリのことです。AndroidはBSDのCライブラリを基にして独自開発されたものを使っています。Linuxの標準Cライブラリは一般的なglibc(GNU libc)です。TermuxのアプリのコンパイルはAndroid NDKを使ってビルドされているようで、このあたり、ちょっと独自にいろいろビルドしてみるときはハマりそうですね。
ちなみに、termuxの提供されているパッケージは以下にあります。

https://grimler.se/termux-packages-24/arm/
：：
1058個が提供されているようです（この執筆時）

apacheやnginxやphpやmariadbなどありますので、wordpressを動かすことはできそうですね。imagemagickなんとかもあるようです。

次は、AnLinuxです。これは先に紹介したTermuxと連携して動作させるものです。Termuxは、prootを使えば独自のファイルシステムを作れます。そのスクリプトを作ってくれています。

貼り付けた画像_2020_08_24_1_54

Step1で、ディストロを選択し、Step2でそのスクリプトをwgetするコマンドをTermuxに貼り付けて動作させるようです。

貼り付けた画像_2020_08_24_1_57

このコピーしたコマンドは以下です。

pkg install wget openssl-tool proot tar -y && hash -r && wget https://raw.githubusercontent.com/EXALAB/AnLinux-Resources/master/Scripts/Installer/CentOS/centos.sh && bash centos.sh

どんなスクリプトが書かれているか、上記のcentos.shを見ると納得します。

貼り付けた画像_2020_08_24_0_29

こんな感じで、prootのCentOSに入れます。この環境で動作させたUnixBenchは以下となります。

yum -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

Shell8のテストでこけるので、コマンドは以下で実行してあります。

./Run -i 1 -v

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

System: localhost: GNU/Linux
OS: GNU/Linux — 4.14.141+ — #1 SMP PREEMPT Wed May 6 10:13:36 CST 2020
Machine: aarch64 (aarch64)
Language: en_US.utf8 (charmap=”ANSI_X3.4-1968″, collate=”ANSI_X3.4-1968″)
; runlevel

————————————————————————
Benchmark Run: Sun Aug 23 2020 16:34:32 – 16:41:18
8 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables 18468392.0 lps (10.0 s, 1 samples)
Double-Precision Whetstone 3423.8 MWIPS (9.5 s, 1 samples)
Execl Throughput 415.5 lps (29.2 s, 1 samples)
File Copy 1024 bufsize 2000 maxblocks 249987.0 KBps (30.0 s, 1 samples)
File Copy 256 bufsize 500 maxblocks 72847.0 KBps (30.0 s, 1 samples)
File Copy 4096 bufsize 8000 maxblocks 694986.0 KBps (30.0 s, 1 samples)
Pipe Throughput 387272.6 lps (10.0 s, 1 samples)
Pipe-based Context Switching 64785.7 lps (10.0 s, 1 samples)
Process Creation 2060.3 lps (30.0 s, 1 samples)
Shell Scripts (1 concurrent) 425.8 lpm (60.2 s, 1 samples)
Shell Scripts (8 concurrent) 100.4 lpm (60.3 s, 1 samples)
System Call Overhead 19692.3 lps (10.1 s, 1 samples)

System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 18468392.0 1582.6
Double-Precision Whetstone 55.0 3423.8 622.5
Execl Throughput 43.0 415.5 96.6
File Copy 1024 bufsize 2000 maxblocks 3960.0 249987.0 631.3
File Copy 256 bufsize 500 maxblocks 1655.0 72847.0 440.2
File Copy 4096 bufsize 8000 maxblocks 5800.0 694986.0 1198.3
Pipe Throughput 12440.0 387272.6 311.3
Pipe-based Context Switching 4000.0 64785.7 162.0
Process Creation 126.0 2060.3 163.5
Shell Scripts (1 concurrent) 42.4 425.8 100.4
Shell Scripts (8 concurrent) 6.0 100.4 167.4
System Call Overhead 15000.0 19692.3 13.1
========
System Benchmarks Index Score 249.3

————————————————————————
Benchmark Run: Sun Aug 23 2020 16:41:18 – 16:48:52
8 CPUs in system; running 8 parallel copies of tests

Dhrystone 2 using register variables 108060066.0 lps (10.1 s, 1 samples)
Double-Precision Whetstone 22455.1 MWIPS (9.1 s, 1 samples)
Execl Throughput 851.2 lps (29.7 s, 1 samples)
File Copy 1024 bufsize 2000 maxblocks 392189.0 KBps (30.0 s, 1 samples)
File Copy 256 bufsize 500 maxblocks 106747.0 KBps (30.0 s, 1 samples)
File Copy 4096 bufsize 8000 maxblocks 1134886.0 KBps (30.0 s, 1 samples)
Pipe Throughput 2149129.5 lps (10.1 s, 1 samples)
Pipe-based Context Switching 272235.0 lps (10.1 s, 1 samples)
Process Creation 5234.7 lps (30.2 s, 1 samples)
Shell Scripts (1 concurrent) 916.4 lpm (61.0 s, 1 samples)
Shell Scripts (8 concurrent) 165.0 lpm (69.8 s, 1 samples)
System Call Overhead 30266.2 lps (10.2 s, 1 samples)

System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 108060066.0 9259.6
Double-Precision Whetstone 55.0 22455.1 4082.7
Execl Throughput 43.0 851.2 197.9
File Copy 1024 bufsize 2000 maxblocks 3960.0 392189.0 990.4
File Copy 256 bufsize 500 maxblocks 1655.0 106747.0 645.0
File Copy 4096 bufsize 8000 maxblocks 5800.0 1134886.0 1956.7
Pipe Throughput 12440.0 2149129.5 1727.6
Pipe-based Context Switching 4000.0 272235.0 680.6
Process Creation 126.0 5234.7 415.5
Shell Scripts (1 concurrent) 42.4 916.4 216.1
Shell Scripts (8 concurrent) 6.0 165.0 275.0
System Call Overhead 15000.0 30266.2 20.2
========
System Benchmarks Index Score 648.0

UserLAndの時と似たような数値ですね。prootするとこのあたりのスコアになるようです。

単純に、UnixBenchのスコアだけだとTermuxが良さそうですが、実際にアプリケーションを動作させてWordPressがどのくらいのレスポンスが出るのか確認しないとですね。

以下のサイトには、スマホをPoCとして活用するため簡単な検証がされています。

https://m.blog.naver.com/PostView.nhn?blogId=nettrail&logNo=221588044681&proxyReferer=https:%2F%2Fwww.google.com%2F

興味深いことに、Termux環境でprootした(AnLinuxで作ったDebian)　apache abテストのほうが14秒（20秒に対して）で速かったということです。UnixBenchの値とは逆行する結果となっています。

Debianのarm環境が優れているからなのか、そのあたりは良くわかりませんが、この筆者はTermuxのネイティブ環境はサポートしているパッケージも少ないので、AnLinuxでproot したディストリ環境のほうが良いんじゃないの？　って結論しています。PoC（Proof of Conceptの略で、「概念実証」）用途ではね。

一回、apache + php7 + mariadb　の同じ環境を使ってWordPressを入れてベンチマークして見たいですね。このブログ運営くらいなら耐えられそうな気もしますがどうでしょうか。

 

投稿日: 更新日:2020年7月2日 Blog, Linux, Win10, WordPress

130W電源でThinkCentre M75q-1 Tinyのベンチマーク

ヤフオクで、130W電源が安く手に入ったのでThinkCentre M75q-1 Tinyにつけてベンチマークを測りなおしました。

Dell ACアダプター 130W   DA130PE1-00 未使用品

ab

まずは、Windows10環境で Cinebench R15とR20から。CPUは微増で OpenGLが少し上がった感じ。

Bench 65W

Cinebench R15
　130W → 41.57
　65W → 35.77

もっと上がると思ったんですが、約1.2倍くらいしかあがりませんでした。

Cinebench R20
　130W → 1715
　65W → 1658

BenchR20

Cinebench R20は、 OpenGL がないので1.03倍という結果。

ついでに、Linux環境でUnixBench も計測。結果から。1.02倍。

UnixBench
　130W → 6552.1
　65W → 6422.2

------------------------------------------------------------------------
Benchmark Run: 水 7月 01 2020 17:02:14 - 17:30:11
8 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables       48809334.1 lps   (10.0 s, 7 samples)
Double-Precision Whetstone 8052.3 MWIPS (10.0 s, 7 samples)
Execl Throughput 7233.2 lps (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 1373280.7 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 394559.8 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 2619298.9 KBps (30.0 s, 2 samples)
Pipe Throughput 2467120.3 lps (10.0 s, 7 samples)
Pipe-based Context Switching 281042.3 lps (10.0 s, 7 samples)
Process Creation 11452.9 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 6733.3 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 3395.6 lpm (60.0 s, 2 samples)
System Call Overhead 3375563.4 lps (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables 116700.0 48809334.1 4182.5
Double-Precision Whetstone 55.0 8052.3 1464.1
Execl Throughput 43.0 7233.2 1682.1
File Copy 1024 bufsize 2000 maxblocks 3960.0 1373280.7 3467.9
File Copy 256 bufsize 500 maxblocks 1655.0 394559.8 2384.0
File Copy 4096 bufsize 8000 maxblocks 5800.0 2619298.9 4516.0
Pipe Throughput 12440.0 2467120.3 1983.2
Pipe-based Context Switching 4000.0 281042.3 702.6
Process Creation 126.0 11452.9 909.0
Shell Scripts (1 concurrent) 42.4 6733.3 1588.0
Shell Scripts (8 concurrent) 6.0 3395.6 5659.3
System Call Overhead 15000.0 3375563.4 2250.4
========
System Benchmarks Index Score 2151.7

------------------------------------------------------------------------
Benchmark Run: 水 7月 01 2020 17:30:11 - 17:58:07
8 CPUs in system; running 8 parallel copies of tests

Dhrystone 2 using register variables      236861099.2 lps   (10.0 s, 7 samples)
Double-Precision Whetstone 51317.7 MWIPS (9.2 s, 7 samples)
Execl Throughput 35004.0 lps (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 1350133.2 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 345639.6 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 3243438.3 KBps (30.0 s, 2 samples)
Pipe Throughput 13437842.8 lps (10.0 s, 7 samples)
Pipe-based Context Switching 1406286.6 lps (10.0 s, 7 samples)
Process Creation 62455.5 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 31016.9 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 4268.4 lpm (60.1 s, 2 samples)
System Call Overhead 15614587.3 lps (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables 116700.0 236861099.2 20296.6
Double-Precision Whetstone 55.0 51317.7 9330.5
Execl Throughput 43.0 35004.0 8140.5
File Copy 1024 bufsize 2000 maxblocks 3960.0 1350133.2 3409.4
File Copy 256 bufsize 500 maxblocks 1655.0 345639.6 2088.5
File Copy 4096 bufsize 8000 maxblocks 5800.0 3243438.3 5592.1
Pipe Throughput 12440.0 13437842.8 10802.1
Pipe-based Context Switching 4000.0 1406286.6 3515.7
Process Creation 126.0 62455.5 4956.8
Shell Scripts (1 concurrent) 42.4 31016.9 7315.3
Shell Scripts (8 concurrent) 6.0 4268.4 7114.0
System Call Overhead 15000.0 15614587.3 10409.7
========
System Benchmarks Index Score 6552.1

うーん、微妙な結果でしたね。実際に、ゲームのベンチマークソフトで計測しないとわからないので、また追加でテストしてみたいです。

 

投稿日: 更新日:2020年5月30日 Blog, ClassicPress, Multisite, WordPress

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

ちょっと時間が空いてしまいましたが、自宅サーバでClassicPressを立ち上げるプロジェクトの続きです。マルチサイト機能を使ってClassicPressを運用してみることにしますが、まずはローカルのMAMP Pro 環境でやって流れを掴んでみることにします。

今回はサブドメインでの運用を想定していて、大まかな流れは以下のようになります。

①名前解決で同じサーバに向ける
DNS周り、またはhosts で以下ドメインを１つのサーバに向けるよう設定します。
または、ワイルドカード DNS の設定をします。今回はローカルで以下のようにHOSTSをいじりました。
例：gpl.jp → 127.0.0.1
www.gpl.jp → 127.0.0.1
hoge.gpl.jp → 127.0.0.1
hack.gpl.jp → 127.0.0.1

②WEBの設定で、*.gpl.jp を同じWEBROOTを見に行くよう設定

③WEBROOTにClassicPressを展開
→wp-config.php のDB設定
DBはもう作ってあるものとします。

④WEBアクセスしてClassicPressをインストール
→　普通にウィザードに沿ってインストールするだけです。

⑤wp-config.php へ設定を記載
define(‘WP_ALLOW_MULTISITE’, true);

⑥管理画面へログインし、サイトネットワークの設定　へ
→ サブドメイン型でインストール

⑦インストール完了すると以下のように指示が出てきます。
wp-config.php と .htaccessへ指示通りに記載

————- wp-config.php

define(‘MULTISITE’, true);
define(‘SUBDOMAIN_INSTALL’, true);
define(‘DOMAIN_CURRENT_SITE’, ‘gpl.jp’);
define(‘PATH_CURRENT_SITE’, ‘/’);
define(‘SITE_ID_CURRENT_SITE’, 1);
define(‘BLOG_ID_CURRENT_SITE’, 1);

————- .htaccess

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]

# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ – [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L]

⑧再度、ログオフ、ログインしてサイトネットワーク管理の管理画面にアクセス
→ 設定＞サイトネットワークの設定　から各種設定
→ 管理メニューを有効化（プラグイン）

以上で、OK。新規サイトを追加する場合は以下。

①サイトネットワーク管理　から追加
サイト＞新規追加サイトを追加_‹_サイトネットワーク管理__GPLJPオフィシャルサイト_—_ClassicPress.png

以上で、複数のClassicPressサイトが出来上がり。基本WordPressと同じですね。

マルチサイトの運用はいろいろ勘所がいると思いますので不定期に何か気がついたら書いていくことにします。管理系のプラグインは便利そうなのが出ているので何か見繕って使っていくと思います。

https://ja.wordpress.org/plugins/search/Multisite/

次回は、とりあえずローカルのMAMP環境で以下をやってみたいと思います。

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

うまくできるかな？