WordPressに大量のデータを投入するための管理システムを構築しておりまして。
そこでWordPressに投稿する際に使うxmlrpcのレスポンスが遅いため、その対策について書いておきます。
目的、というか背景
WordPressに大量データを投入するために、別途管理システムを構築したのは理由がありまして。
一つは「WordPress管理画面の動きがもっさりした遅さ」。
もう一つは「投入するデータが別サーバにあり、そこでいつも管理している」。
とまあこんな理由でして。
別サーバのデータを目視でWordPress管理画面から人力投稿、なんて事アホらしくて・・。
じゃあ、xmlrpcを使って投稿しましょう、という事になったわけです。
それは良いのですが。
管理システムはサクサク動くのに、WordPress側が遅いのなんのって・・。
xmlrpcで１件投稿するのに１～２秒かかってしまうわけなんです。
それって別に遅くないんじゃ・・・いやいやとんでもない。
１件１件はそれほどでもないですが、まとめて１万件以上投稿するとなった場合に１秒の違いはとてつもなく大きいわけでして。
先に結論
という事であれこれ試行錯誤した結果が以下。
innodb_flush_log_at_trx_commit = 0
を、my.cnf に入れるか 直接設定してあげてください。
簡単に説明
xmlrpcの処理時間が遅い＝記事投稿が遅い、という事は データベースへの書き込みに時間がかかる、という事でして。
WordPress相手ですから、そちらの処理を変える訳にもいかないし、インデックスを消す、といった事も出来ません。
よくあるＳＱＬチューニングを行う訳には行かないのです。
また、webサーバ側のチューニングは済んでいると思って下さい。
言い忘れておりましたが、最近流行りの kusanagi を使ったWordPressサイトに対するチューニングなのです。
メモリ、CPU数に応じた最適値の設定、nginx+php7(orHHVM)といったミドルウェア構成の最適化は行われている前提だと考えて下さい。
当然この設定には、MySQLサーバに対する設定も行われておりました。
そうなると、MySQLの更新速度を上げる方法も限られてしまいます。
そんな中で設定した上のパラメータ変更。
実はリスクを伴うものでして。
通常は、データ保全のためトランザクションコミットのタイミングでログファイルに書き出されるようになっているのですが。
上記パラメータを設定すると、ログファイルの書き込みタイミングが１秒毎となってしまうのです。
つまり、トランザクションコミット～次の書き込みまでにサーバが落ちるなどすると、コミットしたはずのデータが失われてしまう可能性があるのです。
ただ、まあ今回はWordPressサイトが対象で、元となるデータは管理システム側にあるわけですから、最悪消えてしまっても問題は無いわけで・・これを良しとしたわけです。
で、このパラメータを設定すると。
今まで２秒かかっていたものが、およそ１／３くらいまで（０．６秒とか）まで短縮できてしまったのです！
これは大きいです！
ここまで差が出た要因は・・WordPress内部の動きなので推測でしかありませんが。
１回の投稿でWordPressは最低５つのテーブルに対しinsertを行うと思っておりまして（wp_posts,wp_postmeta,wp_terms,wp_term_relationships,wp_term_taxonomy）。
それぞれのテーブルに insertするたびにcommitしているんじゃないのか？と思っております（本当か？なんか自分で書いていて嘘くさいと思ってしまう理由だけど・・）。
となると、１回の投稿で５回はcommitしているわけで、それはつまり５回ディスクへアクセスしているのと同じになるわけですね。
速度の遅いディスクへのアクセスをそんなに頻繁に行われたら、そりゃあ投稿に時間がかかるわけです。
そういう推測のもと、上のパラメータが効果を奏したのではないかと考えております。
その他、行うともしかすると速くなるかも？と思った策
訳あって試してはいませんが。
・パーティショニング（どうやって分けるか悩んで諦めました）
・データベースファイル（特にログファイル）のメモリディスク化（ファイル単位で出来るかどうか分からないからやってないです）
・データベース領域だけ別ディスクにする（クラウド＝仮想ディスクなので意味あるかどうか疑問に感じ試していません）
というのも考えてみました。
考えただけで効果があるかどうかは分かりませんよ。
まあ、こんなかんじで。
チューニングって、時間ばっかりかかってしまい期待した結果を得られるかどうか分からないからキライ。