カテゴリー
オープンソース システム関連

WordPressの投稿の保存があまりにも遅いのでデータベースの最適化をしてみた話し

このWordpressのサイトで投稿を保存するときに、たまらなく遅くなってきました。MySQLのデータベースをバージョンアップしても変わりません。

そこでMySQLに格納されている投稿データを最適化してみることにしました。最適化といっても、投稿のリビジョンを削除するだけです。十数年Wordpressを使っていますが、リビジョンの機能が追加されたのはいつのことでしょうか? 全くリビジョン管理をしていないので、追加しっぱなしになってデータベースが肥大化しています。

投稿のリビジョンを削除したのは、Optimize Database after Deleting Revisionsというプラグインです。こちらのサイトを参考にして実施してみます。

WordPressのリビジョンとデータベースを最適化 Optimize Database after Deleting Revisionsの設定と使い方 | ウインドミル

ここのサイトはこの情報以外に、PDFでの電子証明書についての情報が記載されて有用なサイトであるが、最近更新頻度が落ちているのは残念である。

SQLを実行してMySQLのデータベースからリビジョンを削除することもできますが、スケジューリングして普段でもリビジョンを削除してくれますので、新しくプラグインを追加することを避けたいのですが、簡単なのでOptimize Database after Deleting Revisionsを導入しました。

リビジョンを削除した結果なのですが、Optimize Database after Deleting Revisionsでリビジョンを削除する前にOptimizeを実行しておけばよかったのですが忘れてしまいました。データベースのバックアップのサイズの削除前と削除後では、およそ3分の1に減っていました。この位、データベースにリビジョンで埋まっていました。

さて、肝心の投稿の更新の実行時間ですが、以前とあまり変わらない残念な結果でした。

その他、対策を考えて行きましょう。最悪は、現在サイトを動かしているさくらインターネットのレンタルサーバーから他のサーバーに移ることでしょうか? 

最近のさくらインターネットは遅くなっているのかな? サーバー自体かデータベースか、それともインターネットの回線か?

さくらインターネットのお安いレンタルサーバーの契約ではダメなのかな?

カテゴリー
オープンソース

しつこくwp-envで試してみたら、WordPressのGutenbergの再利用ブロック一覧は 10個以上表示していたので解決できた話し

WordPressのGutenbergの再利用ブロック一覧は 10個以上表示されないという障害ですが、気になりだしたら停まらなくなりましたので、しつこくwp-envで試してみました。今度は正常に表示されていました。

wp-envは、Dockerを使って簡単にWordpressの開発環境を作成できてしまいます。DockerとNode.jsがインストールできていれば、コマンド2発(インストールと起動)でWordpressが起動できます。詳しくはwordpress.orgのサイトを参照ください。

最初は、wp-envが起動したWordpressのバージョンも一緒なので、何かおかしいかわかりませんでした。気になるのはwp-envでは、Gutenbergのプラグインがインストールされていなくても、編集画面がGutenbergになっていました。そこで、自分のサイトのGutenbergを無効にしてみました。

すると、何ということでしょう。正常に再利用ブロックが10個以上表示されるようになりました。画面はGutenbergのブロックエディタのままです。これで無事に解決です。解決方法がGutenbergプラグインを削除することなんて全く気が付きませんでした。何てオチなんでしょうか・・・。

こう再利用ブロックを見てみると、Amazonのアフリエイト広告ブロックばかりですな。

しかしながら、今はGutenbergのプラグインはインストールして有効にする必要はないのでしょうか? すでにWordpressにGutenbergは組み込まれていると言うことなのでしょうか? Gutenbergがリリースされてから、Gutenbergプラグインをずっとインストールをしていました。

今度は、記事を書いている間に自動保存が動いて、ずっと更新中になってしまうというのは直っていません。こちらもこれから調べていかなければいけません。

とりあずの回避策としては、記事を念のため一旦クリップボードにコピーしてブラウザの更新ボタンを押します。ブラウザから「サイトを再読込しますか?」という警告(Chromeの場合)が表示されますが、そのまま「再読込み」ボタンを押します。次に「バックアップから復元」ボタンが左上に出てきますので押せば元に戻ります。

続きはこちらから

カテゴリー
オープンソース

WordPressのGutenbergの再利用ブロック一覧は 10個以上表示されない障害のその後と回避策の話し

WordPressのGutenbergの再利用ブロック一覧は 10個以上表示されない障害のその後の話しと、とりあえずの回避策の話しです。解決に至っていません。

あれからGutenbergのソースを追ってみましたけど、10個以上表示しないようにフィルターをかけているなんてしなさそうでした。当たり前だけど。再利用ブロックの一覧を表示しているのは、以下のところでしょうか。

packages\block-editor\src\components\inserter\hooks\use-block-types-state.js
packages\block-editor\src\components\inserter\reusable-blocks-tab.js
packages\block-editor\src\components\block-types-list\index.js

それにしても、GutenbergはReactで記述されているのすね。ソースを追ってみたと言っても、Reactはあまりわかっていないので、何となくこんなことをやっているなんて感じでソースを追っています。

今回でわかったのは、再利用ブロックはどこに格納しているかというと、投稿と同じpostのテーブルなんですね。Gutenbergからどうやって取得しているかは、

select( 'core/block-editor' );

が何かやっているようでした。そもそもwp.data.を付けずに、select()でどうして動いているかも、まだ理解していません。デバッグ環境を作って追っていければいいのですが、まだそこまでやっていません。

そもそも、いちいち再利用ブロックが出てくるたびに、データベースを参照するなんてコストが高いと思うのですが、そこのところは上手くやっているのでしょうね。そうではないと、キャッシュ必須になってしまいます。

また、自分のサイトが悪いのどうか切り分けるため、試しに新しくWordpressのサイトを立てて見ました。今回は簡単にWordpressのDockerイメージで起動します。簡単にテストでサーバーを起動するのはDockerが便利です。Dockerイメージを用意してくれると、とても助かります。

クィックスタート: Compose と WordPress — Docker-docs-ja 17.06 ドキュメント

結果は、やはり再利用ブロックの一覧は10個以上表示できませんでした。サイトの固有の問題ではなさそうです。ただ、再利用ブロックのインポートとエクスポートは正しく動いていました。まとめてインポート/エクスポートできないのが仕方ないのでしょうか。

プラグインもすべて無効にしても変わりません。Gutenbergのブラグインだけでも、再利用ブロック一覧が10個以上表示できない障害が出ています。

こちらの障害は、Gutenbergの開発コミュニティに報告しなければいけませんかね。いろいろ報告の前段階の説明を読むと、面倒なことが書かれているのですので敷居が高そうです。

試しに再利用ブロックを非公開したらリストに反映されずに、よく使うブロックを10個までにしておけばいいかと思いましたが、非公開にしてしまうと記事にほうに表示できなくなってしまうのでした。この回避策は使えません。

もう一つの回避策としては、再利用ブロックのリストは新しく作成した順に10個だけ表示しているので、よく使う再利用ブロックの作成日付を新しい順になるように「すべての再利用ブロックの管理」から変更しておくことです。しかし、新しい順で11番目を使いたいときには、再度日付を更新するという面倒な作業が発生します。

以上、全くGutenbergの再利用ブロックの一覧が10個しか出てこない問題は解決していません。

続きはこちらから