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テーブルとかルーティングとかいじれないので工夫が必要ですね。

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

備忘録: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
::

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

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

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

ハマりどころ1

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

j.gpl.jp

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

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

では、2文字でやって見ましょう。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 でやってみたがだめ。

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から配信しないのがいいですね。ここで見せる画像なんかは、特にこだわりはないので問題ありませんが。

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

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

ポートフォワードの経路で、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で配布して、リバースプロキシーと対応付けしないとだめですので、完璧を求めるならそれらが必要です。そのうち、作る機会があれば紹介したいなと思います。