投稿日: 2022年5月5日2023年7月19日更新日:2023年7月19日 WordPress, 新ブログ, 高速化

アルゴリア検索を導入してみたら、速くて便利で気に入った話！

じゃんくはっく

静的サイトでも動作する検索を模索してみたよ

Google検索とかじゃなくて？

ぴー

じゃんくはっく

自分のサイトにもっと特化して検索できるやつが欲しかったのよ

このブログってGitHub Pagesでしょ？どうやるのかしら？

ぴー

ゴールデンウィーク真っ最中ですね！皆さんは何してますか？

僕は、まったりとPCと戯れて、世界中の面白いネタを探しています。もうね、あるわあるわ。面白ネタがたくさんあって、世界は広いなと、再認識しました。

さて、今回のネタは「検索」です。このブログはgithub pages ってのを使っていて静的なサイトなんです。見た目はWordPressのブログサイトっぽいのですが、htmlとcssとjsだけの構成でPHPとかデータベースとか動作していないんです。なので、自分のサイトの検索機能はGoogleのを使っているんですが、もっと良いのはないかなーと探していました。こういう分野のエンジニアは、フロントエンド・エンジニアと、いうんですが、自分は苦手分野なのであまり知識がありませんでした。

見つけたところは、Electronのサイト！

Electronえれくとろんっていう、仕組みがあるのですがこの本家サイトの日本語ドキュメントにその良い例が載っています。

Electron ドキュメント
https://www.electronjs.org/ja/docs/latest/

このサイトを見ると、キーボード操作 CMD＋K で検索ウィンドウが出てきます。

こんな感じで、検索文字をタイプするごとにそのキーワードを含んだページとヒットした文字部分が出てくるわけです。検索キーワードの提案（サジェスト）が出るのではなく、検索結果がリアルタイムで表示されるイメージです。このキーワードに対して、その候補のページが出てくる仕組み・検索システムが優秀で使いやすいんです。

で、この仕組みってどうやって作っているんだろうなーと思っていたところ、このウインドウの下にはalgoliaあるごりあと表示されています。どうやら、algolia の検索システムを使っているようです。

ちなみに、Electronっていのは、簡単に紹介すると以下です。そのうち、ネタにしようかなと思っています

Electron（エレクトロン）とは、ウェブ技術でデスクトップアプリケーションを作成できるテクノロジーです。 HTMLとCSS、JavaScriptを使って開発し、WindowsとmacOSの両OSのアプリケーションを1つのコードから作ることができます。
https://ics.media/entry/7298/

algolia の検索システムとは何なのか？

さて、algoliaの検索とはいったい何なのでしょうか？英語サイトですが、サービス名称は「Algolia Searchあるごりあ　さーち」と言うようです。

Algolia Search
https://www.algolia.com/products/search-and-discovery/hosted-search-api/

FAQのところを見ると、概要が見えてきます。まず、Algoliaは高速で、SaaSさーす製品でモバイル向けにも特化してあり、日本語も使えるようです。

機能は大きくわけて、２つあるようです。１つは、Autocompleteと呼ばれる、検索キーワードを入れると、リアルタイムで検索結果が出る仕組み。もう一つは、検索キーワードの提案（サジェスト）のAutoCompleteで、これは「Query Suggestions」を設定すると可能のようです。

こういうのは、まず使ってみるのが手っ取り早いです。幸い、WordPressでalgolia検索を使うのは簡単です。まずは、このサイトですでに実装してあるので、それを紹介してみます。

このブログでの実装例

このブログでは、キーボード操作「/」スラッシュをタイプすると、以下のような検索ウィンドウが出てきます。

検索テキスト入力エリアにフォーカスするには、「.」ドットをタイプするかマウスでフォーカスします。適当な検索ワードをタイプすればその結果を含むページが下に表示されます。これは、検索キーワードのサジェストとは違いますが、検索結果がすぐに出てくるので検索結果に遷移しなくても良くて便利です。検索ワードをタイプしてから、検索結果が出てくるのが異常に速くないでしょうか？

WordPressに入れてみる

では、このブログと同じことをしてみたい人向けに具体的な手順の紹介です。２つプラグインを入れるのですが、まず、１つ目は以下です。

WP Search with Algolia
https://ja.wordpress.org/plugins/wp-search-with-algolia/

次に、algolia のサイトではアカウントを作成し、Applicationを作成し、APIキーを参照します。

で、その各種項目を先ほどのWordPressプラグインに設定します。

少し説明は端折りますが、「Search Page」では、とりあえず真ん中の「Use Algolia in the backend」を選んでおけば良いでしょう。Autocomplete では、検索させる対象、たとえば「投稿」を選択してインデックスを再作成しておきます。

WP標準の検索ウィンドウで確認

WP標準の検索ウィンドウで、検索キーワードを入れたら、検索結果が出てくるようになっていれば成功です。

アイキャッチ記事の画像があれば、こんな感じで表示されるかなと思います。

キーボード操作で検索ウィンドウを出す

続いて、キーボード操作で、検索窓がポップアップする部分です。検索結果に遷移しなくて良いので、どのページからも検索ウィンドウが表示されれば便利かなと思いました。

そのような動作をするプラグインを昔みたことがあったので検索してみました。「wp-keyboard-nav」というのがあったので、それには検索窓がついていないので、少し手直しして、以下のような野良プラグインを作ってみました。

Keyboard PopUP algolia search
WordPress の野良プラグインです。プラグイン名称は、Keyboard PopUP algolia search です。キーボード操作でポップアップする検索ウィンドウです。algolia検索と組み合わせて使うために、改造しました。元ソースは、wp-keyboard-nav LINK というプラグインです。
https://github.com/take-i/wp-keypopup-algolia

こちらは何も設定は必要ありません。プラグインを入れれば、すべてのページでキーボード操作で検索ウィンドウが出てくるかと思います。

レスポンス時間はどのくらいなのか？

検索ウィンドウに１文字づつタイプするごとに、Algolia のAPIにリクエストが飛び、レスポンスされます。何回か試したのですが、ほとんどが100ms 以内に帰ってきています。

以下のように、20ms以内くらいで帰ってくるようです。劇速いです！

まとめ

今回、なんとなくわかったのは以下となります。

・Algolia の無料枠は、10,000検索リクエスト/月
・検索対象の数制限は、10,000 レコード
・無料枠利用にカード登録は必要なし
・個人用サイトなら無料枠で足りそうだが、しばらく運用してみる
・有料版は、1000リクエスト/月で1.5ドル
・検索クエリーは１文字づつ、APIリクエストが飛んでいる
・その、ほとんどが20ms以内にレスポンスされている
・検索結果が検索窓に検索キーワードを入れた時点で表示される
・↑これがすごく便利で気に入りました
・日本語にも対応していている
・紹介はしきれなかったが、静的サイトでも少しの手入れで動作する
・速いというのは、正義だなと改めて実感
・キーボードで出てくる検索ウィンドウは思ったより、便利
・algolia にINDEXデータを入れる部分はwordpressで可能
・algoliaの管理画面でAnalyticsがあり、検索ワードや表示ページなど統計データが見れる

あとがき

英語サイトの情報なので、まだあまり日本語の情報がないのですが、この手のサイト内検索を商材にするサービスは他にもたくさんあります。商用のサイトなら、たくさんある商品や情報の中から、お客さんが希望するモノにたどり着きやすくするため、サイト内検索は結構重要だと思っています。

今回の話は、バックエンドにデータベースがあって、それを直接検索参照させる従来のやり方ではないケースです。このブログのように、静的なページがあってそれを対象に高速で検索させる場合は何が正解なのでしょうか。ある人は、全文検索エンジンを入れたらどう？とか。検索用のインデッックスを持ったDBを用意すればよいとか。

このブログの場合は、記事の作成時点ではWordPressで管理していて、書き出すときに静的なHTMLにしています。全ての記事のインデックス（目次情報）は、WordPressで動作している時点でAlgolia に投げられます。静的ページからの検索は、JavaScript経由でAlgoliaに参照され、文字が入るたびにリアルタイムに検索結果が表示される仕組みです。

データベースは無く、作るつもりもないので静的ページをどうやって手間なく、検索させるか？の１つの解だとは思います。

著者にメッセージ

間違いのご指摘など、コメントじゃなくて、個人的にやりとりしたい場合はこちらからどうぞ。お返事が遅くなるときもありますが、ご了承を。

投稿日: 2022年1月2日2022年1月2日更新日:2022年1月2日 Android, cdn, Linux, WordPress, 高速化

KeyCDNという安いCDNを半年使った感想、価格や月維持費などレポート！

じゃんくはっく

CDNってのを半年、使ってみましたよ

クラウドからコンテンツを配信するってヤツですね。

ぴー

じゃんくはっく

どんな効果があって、月維持費はどのくらいかレポートしてみます。

私は、月500円くらいまでなら出せるかなー

ぴー

KeyCDNは数年前、１位か２位くらいの安さでしたが、今はもっと安いのがあるようです。CDNのコスト計算サイトでは以下のようでした。blazingcdnというのが破格の安さのようです。

今回は前から気になっていたKeyCDNをこのスマホサーバのWordPressサイトに適用してみましたので、実際どのくらいの値段で運用できるんだ？　みたいな感想をレポートしてみたいと思います。

そもそもCDNって何？

CDNは平たく言えば、画像やコンテンツを本家とは違うサーバから配信するというものです。キャッシュサーバとか、エッジサーバとか表現したりしますが、要は静的なファイルを本家サーバからではなく、CDNのクラウドから配信することによりネットワーク負荷や、レスポンス改善（時に改悪）したりするのが目的です。

コンテンツデリバリネットワーク（英語: content delivery network、CDN）
wiki

いくらするの？

ほとんどの人が気になるのは、初期や維持費などの価格がいくらなのか？　っていうことと、速度はどのくらい改善されるのか？　ってことだと思います。こればっかりは使ってみないとなんとも言えない部分があります。早速、値段からレポートしてみたいと思います。

　まず、KeyCDNは最初にクレジットを入れてそれを消費する仕組みです。最小の入金単位は 49ドルとなります。日本円で当時のキャッシュカード換金レートで、5,553円でした。

　入金したのが、2021年の06月/01なので現時点で半年使っていることになります。クレジットの消費は以下のようになっています。

残りクレジットは18くらいです。49から約36%残っていますので半年で67% 消費したことになります。半年で、約3720円ですので、１ヶ月あたり620円という感じですね。

　グラフの途中に、ガクンとクレジットが消費しているところがありますが、これはキャッシュを完全に消去して作り直している部分です。

どのくらいのアクセス数なの？

統計期間が約４ヶ月くらいなので、KeyCDN上のデータでは以下のようです。

1日あたり、cssや画像やhtmlなど合計して1.8万くらいのヒットがあります。PV的な数値は１つ前の記事に載せてありますので、参考にしてください。

１ヶ月のデータ転送量は？

このサイトの１ヶ月のデータ転送量（総トラフィック）は、KeyCDNの統計データで見ると以下のようです。

PV的には2000〜2500くらいでこの転送量です。3000〜5000くらいのPVでも15GBを１ヶ月に超えることはありませんでした。

CDNの効果はどのくらい？

ページ計測サイトで、CDN適用前と適用後のデータを測っておきましたので載せておきます。

まずは、CDN適用前。

次は、CDN適用後。

だいぶ改善されていますね。適用前は、最初のレンダリングが始まるのに、約4.2秒かかっていますが、適用後は、0.8秒です。CDNの効果は絶大です。

まとめ

今回、なんとなくわかったのは以下となります。

・このサイトのようにPVが月に２０００〜５０００くらいでは、月600円〜700円くらいのCDNコスト

・設定は非常に楽

・CDNの効果は絶大で、最初の描画が4.2秒から0.8秒となった

・blazingcdnというCDNはKeyCDNより激安で、どんな効果があるのか試してみたい気もする

あとがき

WordPressのように、コンテンツ側で結構リソースを使うタイプや、スマホサーバのように非力な環境ではCDNの効力は絶大です。しかし、利用コストが月に600円〜700円くらいかかり趣味で使うのなら良いのですが、静的HTMLにして運用したほうが、良いなという結論に至りました。要はWordPressは、リソースを使うし無駄が多いんです。近々、そういう運用に方針を変えますので、紹介したいなと思っています。

著者にメッセージ

間違いのご指摘など、コメントじゃなくて、個人的にやりとりしたい場合はこちらからどうぞ。お返事が遅くなるときもありますが、ご了承を。

投稿日: 2020年9月12日更新日:2020年9月12日 Blog, WordPress, 高速化

スマホ上に作った自宅サーバのWordPressで、テスト評価がほぼオールAになった！

はい、ただ今引っ越し準備中でして、このブログをスマートフォン上に作ったWordPressサーバに引っ越しします。９月末か１０月頭予定で各種チューニングをやっていましたが、ついにスピードテスト系の評価サイトでほぼオールAを取ることに成功しました。

いくつかある評価サイトの中では、ここが一番好きです。ここの計測サイトは東京リージョンもあり、また各種グラフが見やすくビデオプレビューまで付いて来ます。

WEBPAGETEST
https://www.webpagetest.org/

主な評価観点は、左から以下のようになっています。

セキュリティ
初期アクセスまでの時間
Keep-alive通信がONか？
圧縮転送されているか？
イメージの圧縮はどうか？
静的コンテンツがキャッシュされているか？
CDNを使っているか？

７番のCDNは一部、WordPressのをつかっていますが、全部は使っていないので、x　になっています。これはどうするかまだ迷っています。一度、国内のCDNをテストで使ってみようと思ったのですがうまく動作せずでした。まだ原因がわかっていません。

　難易度的には、簡単なものから３・４・５・６・２・１・７で難しかったです。今回は、自分なりの考えをメモりつつ、１つづつ紹介していきたいなと思います。必ず正解っていう部分はないところでもあるので、あくまで自分はこんな対策と対応をしたよっていう感じです。いろいろツッコミどころはあるとは思いますが、何かあればコメントでお気軽にどうぞ。

難易度G・Keep-alive通信がONか？

これは apache を使おうが、nginx を使おうが最初からデフォルトONになっているので意識せずともAになると思います。今回は、最終的に nginx を使うことにしましたので、nginx.conf に以下を設定しています。タイムアウト時間は短いほうが良いと思います。でも、ここは突き詰めると難しい部分です。興味がある方は、以下などを一読されると良いかなと思います。

ぜんぶTIME_WAITのせいだ！
https://qiita.com/kuni-nakaji/items/c07004c7d9e5bb683bc2

http {
::（省略）
    keepalive_requests 100;
    keepalive_timeout  3;
::（省略）

termux 上の android OSでは、一般的なLinuxと違ってKernelパラメータも調整されているはずですので、ここが何が適切なのかを明確にするには root権限のあるスマホで termux を動かし負荷テストをしながら、各種TCPの状態遷移を見ていくのが正しい姿勢です。という意味では一番難しい部類ですが、今回はそこまで突っ込まないことにします。

難易度F・圧縮転送されているか？

圧縮レベルは１でも十分という意見はありそうです。

http {
::（省略）
    gzip  on;
    gzip_vary       on;
    gzip_proxied    any;
    gzip_comp_level 6;
    gzip_types      text/plain text/css text/xml text/javascript
                    application/json application/javascript application/x-javascript
                    application/xml application/rss+xml application/atom+xml
                    image/svg+xml;
::（省略）

難易度E・イメージの圧縮はどうか？

これは今回は、ジェットパックのプラグインでwordpress のCDN側から画像が出ています。そこで適切に圧縮してくれているので簡単です。ただ、やりだすと奥が深いので、中間くらいの位置付けにしてあります。

難易度D・静的コンテンツがキャッシュされているか？

これは、レスポンスヘッダにNo max-age または expiresをつければ解決します。具体的には、nginxの設定で以下を設定すればOKです。

location ~* \.(jpg|jpeg|gif|png|css|js|swf|ico|pdf|svg|eot|ttf|woff)$ {
    expires 60d;
    add_header Cache-Control "public, no-transform";
    access_log off;
}

難易度C・初期アクセスまでの時間

これは、WordPress側でキャッシュを作るのが一番最速です。各種プラグインがありますが、いろいろ試した結果、今の所はAutoptimizeに落ち着いています。

デフォルト設定でも十分効果はあります。迷ってる設定としては、Google フォントの削除　をするかしないかです。表示の綺麗さを取るか、お客様に快適にアクセスしてもらうのを取るか　ですね。あとは、ネットワーク的な速度の部分があります。今は InterLink の回線上にいますが、少し工夫してある部分といえば、常時利用する経路とは分離してあるくらいでしょうか？　WiFiの5G接続でもこのくらいは出ますよという参考値になればと思います。WiFiルーターの側にスマホ（サーバ）は置いてあります。距離を離すと応答速度が遅れます。

難易度B・セキュリティ

これが結構難しかったです。まず、WordPress の最新を使ってもjquery 1.12.4でした。これは脆弱性があるので、あげて置きたいところですが WordPressはIE8のことも考えて意図的に落としているようです（たぶん）。なので、以下プラグインで上書きしています。

しかし、これ以外もやることがあって以下のチェックサイトに行ったほうがわかりやすいかもしれません。各種セキュリー関連のhttpヘッダーを付与する必要があります。

https://securityheaders.com/

最初はここ、真っ赤でF判定だったです。

対策としては、NGINXの設定でヘッダに以下をつければA判定となりクリアになりますが、まだiFrameの設定が未完結です。X-Frame-Optionsは、古く　Content-Security-Policy　の指定で行うのが良さそうです。frame-ancestors　を指定し組み込める参照元を制限する方法が良いということはわかっているのですが、まだ設定値が決まりません。A判定は取っていますが、内容がない状態です。

add_header Strict-Transport-Security "max-age=15552000"; 
add_header X-XSS-Protection "1; mode=block";
add_header X-Frame-Options SAMEORIGIN;
add_header X-Frame-Options "ALLOW-FROM https://www.youtube.com";
add_header X-Content-Type-Options nosniff;
add_header Content-Security-Policy "default-src * 'self' data: 'unsafe-inline' 'unsafe-eval' ;";
add_header Referrer-Policy strict-origin always;
add_header Permissions-Policy "fullscreen=() geolocation=()";

難易度A・CDNを使っているか？

ここは、DNSの向け先を変えたり、CDNのキャッシュをコントロールしたりする必要があり、運用とも関わる部分です。一度設定したのですが、うまく動作せずここは今の所一番の課題となっています。そもそも、月間５０００ページビューにも行かないこのサイトでCDNを導入する必要があるかどうか？　という点もありますが、一度やって見ないとわかりません。あと仕事ではなく、趣味なので無料のものしか使う気はありません。さて、どこがいいんでしょうかね？

あとがき

このサーバは、スマホで動いていてWiFiの無線で繋がっていますが、こんなちっさな筐体でもWordPressが動く、しかもA評価までもらえるなんて！　感動です。Termuxは最高のアプリですね。神アプリ認定です。

　しかも、常時SSL対応ですよ。もちろん、無料のSSL証明書です。なんだか時代は刻々と進化していますね。

投稿日: 2020年9月10日更新日:2020年9月10日 Linux, WordPress, 高速化

Termuxでのスマホサーバ、SSLアクセスでも耐えれそうかな？

TermuxでのLet’s Encrypt　SSL化がやっとできたのでメモっておきます！

まず心配だったのは、SSLアクセスしたときのレスポンスですが、まぁ我慢どころといった感じでしょうか。

非SSLと比べると、接続には少し時間がかかっています。実際にスマホからSIM通信してみると、若干ワンテンポ送れる感じです。

証明書は、Let’s Encrypt でこれは３ヶ月ごとに更新しないといけないので自動化が必須となってきます。手動でやってもいいのですが、絶対面倒になって証明書を切らしてしまうので。で、自動化には certbot のスクリプトが有名なんですが、これは依存関係などがあったり、root （スクリプト中で su したり）が必須とかで、Termux では動きません。動かす方法もあるのでしょうが、世の中にはもっと小さな自動化ツールがありました！

acme-tiny っていうPython製の自動化PGです。pythonとopenssl があれば動くそうです。pip で入れて見ます。

ステップ１ pythonを入れる

pythonが必要なので、なければ入れます。今回は、もう入れてあるので次です。

$ dpkg-query -l | grep python
ii  python             3.8.5             aarch64      Python 3 programming language intended to enable clear programs

$ pkg install python -y

ステップ２　PIPで acme-tiny を入れる

$ pip install acme-tiny

pip が古いとか言われたら、以下で。

$ python3 -m pip install --upgrade pip

以下に入るようです。

$ which acme-tiny
/data/data/com.termux/files/usr/bin/acme-tiny

$ find $PREFIX -name *acme*
/data/data/com.termux/files/usr/bin/acme-tiny
/data/data/com.termux/files/usr/lib/python3.8/site-packages/acme_tiny.py
/data/data/com.termux/files/usr/lib/python3.8/site-packages/__pycache__/acme_tiny.cpython-38.pyc
/data/data/com.termux/files/usr/lib/python3.8/site-packages/acme_tiny-4.1.0.dist-info

ステップ３　Let’s Encryptアカウントの秘密鍵

どこか適当な場所にディレクトリを作って、そこで作業します。

$ cd
$ mkdir ssl
$ cd ssl
$ openssl genrsa 4096 > account.key

ステップ４　ドメイン用の秘密鍵を作成

ドメイン名は、読み替えてみてください。

$ openssl genrsa 4096 > www.example.jp.key

ステップ５　ドメインの証明書署名要求（CSR）を作成

シングルドメイン
$ openssl req -new -sha256 -key www.example.jp.key -subj "/CN=www.example.jp" > www.example.jp.csr

サブドメインのワイルドカード証明書はどうやって作るのかまだ知りません。課題です。

ステップ６　証明書に署名してもらう

$ mkdir -p /data/data/com.termux/files/home/【WEBROOT】/.well-known/acme-challenge/

$ acme-tiny --disable-check --account-key ./account.key --csr ./www.example.jp.csr --acme-dir /data/data/com.termux/files/home/【WEBROOT】/.well-known/acme-challenge/ > ./www.example.jp.crt

ここで、–disable-check　を入れていますがこれは先日記載したUターンNAT（ヘアピンNAT）ができないため、自分自身のWEBにアクセスできないからです。そういう問題がない場合は、削除してください。

こんな感じで出来ると思います。crtができない場合は何かが悪いです。ログにヒントがありますので慌てず、探りましょう！

.
├── account.key
├── www.example.jp.crt　署名された証明書
├── www.example.jp.csr
└──  www.example.jp.key　鍵

.WEBROOT
    └── .well-known
        └── acme-challenge
           └──xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

ステップ７　nginxの設定

設定ファイル抜粋。ルータとtermuxはポート転送しています。

http {
：：（略）
    ssl_session_timeout 30m;
    ssl_session_cache   shared:SSL:10m;
    ssl_session_tickets off;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
    ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256;
：：（略）
server {
     listen      8443;
：：（略）
     ssl_certificate     /data/data/com.termux/files/home/ssl/www.example.jp.crt;
     ssl_certificate_key /data/data/com.termux/files/home/ssl/www.example.jp.key;
：：（略）

なぜか、location で、.well-known/acme-challenge/　の場所が以下のように指定したら、アクセスできませんでした。なので、これは消して、実際のWEBROOTに/.well-known/acme-challenge/を作りました。

location ^~ /.well-known/acme-challenge/ {
    root /data/data/com.termux/files/home/【acme-challengeがあるパス】;
}
location = /.well-known/acme-challenge/ {
    return 404;
}

以下の評価が先にマッチしてしまって、これも一時的に消しました。

location ~ /\. {
    return 404;
}

nginxの設定、不慣れなんでどこかおかしいんでしょうね。

ワイルドカード証明書が取得できるようにしたら、cronに定期実行してもらおうと思いますが、もう少しいろいろ試してみてからにします。

SSLのチェックも良さそうです。

PageSpeed Insightsのモバイルのスコアも良さそうです。

PC版は１００点出ました！

ということで、Termux のnginxとphp-fpmで無料の証明書を入れて速度的にも問題なさそうかなという感じです。

あとは、今回出たもろもろの問題をクリアにしてマクロを定期実行できればOKです。ぼちぼちやっていきます。でも、10月はじめまでには、移行完了しないといけませんので、それまでにはCDN問題もクリアして試してみたいです。

良くわからんこと！

・nginxのlocationのマッチはどうなってるのか？

・ワイルドカード証明書はどうやって作るのか？CSRの作り方っぽいが？

・リバースプロキシーでSSLアクセスするにはどうしたら？

投稿日: 2020年9月8日更新日:2020年9月8日 Blog, WordPress, 高速化

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

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

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

GCP東京リージョンからの、apache ab は以下。182/sec　〜！速っ　78秒かかっていたテストが５．５秒。あ、これ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フォントは外す方向で。

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

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

投稿日: 2020年9月6日2021年6月2日更新日: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」というのを使いました。

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

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

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

見つけたところは、Electronのサイト！

algolia の検索システムとは何なのか？

このブログでの実装例

WordPressに入れてみる

WP標準の検索ウィンドウで確認

キーボード操作で検索ウィンドウを出す

レスポンス時間はどのくらいなのか？

まとめ

あとがき

著者にメッセージ

そもそもCDNって何？

いくらするの？

どのくらいのアクセス数なの？

１ヶ月のデータ転送量は？

CDNの効果はどのくらい？

まとめ

あとがき

著者にメッセージ

難易度G・Keep-alive通信がONか？

難易度F・圧縮転送されているか？

難易度E・イメージの圧縮はどうか？

難易度D・静的コンテンツがキャッシュされているか？

難易度C・初期アクセスまでの時間

難易度B・セキュリティ

難易度A・CDNを使っているか？

あとがき

ステップ１ pythonを入れる

ステップ２ PIPで acme-tiny を入れる

ステップ３ Let’s Encryptアカウントの秘密鍵

ステップ４ ドメイン用の秘密鍵を作成

ステップ５ ドメインの証明書署名要求（CSR）を作成

ステップ６ 証明書に署名してもらう

ステップ７ nginxの設定

良くわからんこと！

追記

Search

ステップ２　PIPで acme-tiny を入れる

ステップ３　Let’s Encryptアカウントの秘密鍵

ステップ４　ドメイン用の秘密鍵を作成

ステップ５　ドメインの証明書署名要求（CSR）を作成

ステップ６　証明書に署名してもらう

ステップ７　nginxの設定