こんにちは。
こちらの記事では、KUSANAGIユーザー同士が交流している、KUSANAGIユーザーフォーラム内に上がったトピックスをご紹介していきます。
このフォーラムには、KUSANAGIの基本的な使い方から、インストール時・運用時のお悩みまで、様々な課題やその解決方法が投稿されています。
KUSANAGIについて、わからないところや困っていることがある方は、ぜひご参加ください。
今回は、bcache用テーブルの別データベース化に関するトピックです。
WordPressサイトの表示を高速化させるのに必要なコマンド
KUSANAGIには表示の高速化とサーバ負荷の低減を図るための「kusanagi bcache」コマンドが存在します。コマンドの特徴としては、WordPress組み込みのキャッシュシステムを利用し、データのストア先がデータベースである点です。また、PHPで動作するため細やかなコントロールが可能になるというものです。
今回ご紹介するトピックは1年ほど前のもので、KUSANAGI Tech Colum「kusanagi bcache コマンドとその仕組み」を読んで頂いた方から、現状の環境に適用させる場合のLoadAverageにかかる負荷のご質問です。
<寄せられたご質問>
KUSANAGI 8.4.1-2を使用しています。
以下のページにある「３．TIPS bcache用テーブルの別データベース化」についてです。
kusanagi bcache コマンドとその仕組み
現在は以下のようにサーバ2台でサイトを運用しています。
（１）データベースサーバ
（２）WordPressが動作するサーバ
現状は（１）のサーバ内にWordPressのデータベースがあり、その中にbcache用テーブルが存在していますが表示高速化のために、bcache用テーブルだけ切り分けて（2）のサーバの方に置こうかと考えています。
しかし、（2）のサーバはLoadAverageが高くなりやすく悩んでいます。
現在（2）のサーバではデータベースが稼働していないのですが、bcache用テーブルのためにデータベースを稼働させると、さらにLoadAverageが上がってしまいますでしょうか。
＜回答＞
kusanagi status の結果がないので推測で提案します。
nginx を使っているのであれば、fcache を検討してください。
【bcache について】
> しかし、（2）のサーバはLoadAverageが高くなりやすく悩んでいます。
> 現在（2）のサーバではデータベースが稼働していないのですが、
> bcache用テーブルのためにデータベースを稼働させると、さらにLoadAverageが上がってしまいますでしょうか。
はい、新たに DB サービスが立ち上がることになるので、当然ロードアベレージに負荷がかかると思われます。
そもそも、ロードアベレージが上がる原因は多岐にわたります。
まずは、ロードアベレージを引き起こしている原因をきちんと調査することが重要です。
WordPress ではなく別の原因であった場合、WordPress 周りの最適化をしても意味がないことになるかもしれません。
（続きは以下をご覧ください）
KUSANAGIでお困りのことがあれば、KUSANAGIユーザーフォーラムへ
KUSANAGIに関するご質問はもちろん、実装部分などの、不明な点やお困りのことがあれば、ぜひフォーラムにお寄せください。
フォーラムにはユーザーの方々だけでなく、KUSANAGI開発を担当しているメンバーが回答することもありますので、KUSANAGI関連でのお問い合わせであれば、まずはKUSANAGIユーザーグループのフォーラムに質問を投げてみるのもよいかと思います。
また、お仕事やプライベートでKUSANAGIを使っているという方につきましては、ぜひフォーラムの質問への回答者としてもご参加ください！皆さまのご参加をお待ちしております。
もしフォーラムでも解決できなかった場合や、自社で対応が難しい場合やより高度なサービスをご希望される場合は、KUSANAGIマネージドサービスというプライム・ストラテジーのサービスもありますのでご検討下さい。
また、今回ご質問のきっかけとなったKUSANAGI Tech Columはプライム・ストラテジーの開発メンバーによる技術コラムです。こちらも併せてご一読ください。
