Tag Archives: wordpress

MariaDB Galera Cluster の Split-Brain 問題

MySQLのマスター・スレーブ構成からMariaDBのマルチマスター構成に移行してから、DB側の運用は非常に楽になった。wordpressに関して言えばWeb+DBのセットが2つあるので、その単位でラウンドロビンしている限り、まったく問題なく複数台構成を取れる(Webの接続先DBがlocalhostという状態)。しかし、DBのみを分離してreadもwriteも関係なくラウンドロビンさせると、どうしてもdead lockが頻発してしまって不都合が起きやすい。... 続きを読む

IDCFクラウド wordpress 障害対応

今までVPSやGMOクラウド時代に、wordpress運用で障害らしい障害は起こしたことなかった。サーバ運用が硬直的だったので大きな変更を行えなかったというのも理由の1つではあるが。IDCFクラウドへの移行後は、vmwareノード上にlxcコンテナを作成して、そのコンテナ上でwordpressを運用している。更にwordpressのphp部分はGlusterFSで、データ部分はMariaDBで2台を同期している。これだけ構成を複雑化させてしまったせいかもしれないが、遂にwebサーバにて予期しない障害が発生した。... 続きを読む

IDCFクラウド wordpress 複数台構成 構築

wordpressの運用は既に8年近くに渡っているが、まともな複数台運用が実現できていなかった。大したコンテンツではないが、それでもクラウド費用くらいは稼いでくれるので、出来る限りダウンタイムの少ない運用を行いたい。その結果としてwordpressサーバは大胆な停止が行えなくなり、構造変更がまともに出来ず、古臭い構成に成り下がってしまう。クラウドに移行した一番のモチベーションは、複数台構成にすることで頻繁に更新出来る環境を維持したかったからだ。... 続きを読む

DBサーバ 比較 MySQL vs MariaDB 移行編

昔ながらのmaster/slaveでMySQLを運用してきたが、最近は大分考えが変わってきた。少なくとも自分の趣味環境においてはパフォーマンスより運用の利便性を優先しないと作業の生産性が改善しない。MySQLにおいてmaster/slave構成を取ってきたのは、趣味レベルにおいてはわずかでしかない性能を気にしての事。GMOクラウドからIDCFクラウドに引っ越して内部通信品質も大きく改善したので、今回はwordpressのDBをマルチマスターとなるMariaDBのGalera Clusterに移行してみる。... 続きを読む

wordpress 修正のプラグイン化

wordpressの細かい修正を割りとラフにハードコーディングしてきたんだけど、さすがに量も増えてきたし、バージョンアップも多いし、毎回直すのが億劫になってきた。という訳で、いい加減バージョンアップに影響を受けない修正方法を検討する。何となく想像は付いていて、専用のプラグインを作り、コアモジュール以外の部分で修正を行えるように準備する。そのプラグインの中でwidget作ったり、パラメータを上書きしたり、実現したいカスタマイズを実装していく。... 続きを読む

wordpress マルチサイト化 別ドメイン編

前回、検証機でのマルチサイト化に成功したので、同じ設定を本番機に適用する。その上で、サブドメインによるマルチサイトを別ドメインによる複数ドメインのマルチサイトに切り替える。稼働中のサーバに対して変更を実施する場合は、変更適用後に現行サービスの復帰を最優先する。検証機でマルチサイト化後に現状復帰のため必要だった作業は以下。... 続きを読む

wordpress マルチサイト化 サブドメイン編

久々にwordpressネタを。とある事情でもう1つサイトを作る必要が出てきた。別に何で作ってもよかったんだけど、最近はすっかりwordpressを使い込み始めているし、環境も揃っているから、wordpressでささっと作ってみる事にした。当初は律儀にもう1つwordpress環境を作るつもりだったけど、コードの二重修正とか両者の運用的な同期とか手間の方が大きそうなので、マルチインスタンス的なことが出来ないか調べてみた。... 続きを読む

wordpress チューニング (6) nginx編

長々と続けてきた、wordpressチューニング。当初3秒だった処理速度も前回の改善で300msec前後と10倍ほどの高速化に至った。あと残されている改善余地はwebサーバくらいなので今回はnginxを見ていく。webサーバのチューニングにおいて、httpdそのものの処理速度はあまり問題にならないので、通信速度についての改善を考えてみる。nginxのレベルで通信速度をチューニングするとなると、最初に思いつくのはHTMLやcss等のテキストコンテンツの圧縮。設定はそれほど難しくなくnginx.confに以下のような設定を追加する。... 続きを読む

wordpress チューニング (5) plugin編

前回までで、当初3秒だったトップページの表示は400msec前後まで改善した。今回はwordpressのプラグインで処理速度を改善できないか見ていく。クラウド環境の場合、リモートのDB通信がボトルネックになることはわかっているので、出来ればwordpressのロジック内でDBの値をキャッシュ出来ると望ましい。reverse proxy等でページそのものをキャッシュする事も同じような効果を得られるが、その場合はログイン時の出し分けなどが難しくなってしまうことになる。... 続きを読む

wordpress チューニング (4) php編

前回、php-fpmということでサーバプロセスを中心に見てみたが、今回はphpそのものについてのチューニングを考える。今更だけど、phpは仕事で扱った事ないので基本的には門外漢。適当にぐぐってみたところ、opcacheという機能によるチューニングが筋よさそう。opcacheはphp5.5から使えるようなので、現在のphp5.4を一旦消し去って、remiリポジトリからopcacheも加えた形でphp5.5を入れ直す。... 続きを読む

wordpress チューニング (3) php-fpm編

前回のmysql編に続き、今回はphp-fpmを見ていく。apache時代はmod_phpもあったが、nginxの場合はphp-fpmを使う事になる。まあ、mod_php使った場合のリソースのばらつきもひどい有様だったので、リソースの効率的な再利用という意味でphp-fpmの選択は順当と考えている。php-fpmの設定はほぼデフォルトのままだったので改善余地がないか探る。... 続きを読む

wordpress チューニング (2) mysql編

前回のOS編はほぼ改善なしで、相変わらずトップページが3秒かかる状態。早速今回はDB周りで改善余地がないかを見ていこうと思う。まずDBがローカルかリモートかで変化するか確認したところ、mysqlをwordpressが動いているサーバと一緒にするだけで、処理時間が1秒超縮まり、2秒弱で処理できるようになった。もともとクラウドの内部通信は品質低いと思っていたが、これほどとは。。。... 続きを読む

wordpress チューニング (1) OS編

wordpressを自宅環境からクラウド環境に移設した。クラウド上でwordpressを本番稼働させながら、諸々の整備を進めているため、わりと頻繁にchef-clientを実行したりしているのだが、その際のHTTPレスポンスが著しく劣化しているような気がしていた。実際、chef-clientしつつブラウザで触ってみると、ほぼレスポンスできてないに等しい状態が数分続く事になっている(chefの処理も遅い)。... 続きを読む

Count per Dayのカウントを日本のみに

その後も必要に応じてちょこちょこwordpressのプラグインを追加している。それなりに作り直すとやはり気になるのがPVで、自分について言えばアクセスログでも確認できるんだけど、やはりカウンター的なものを設置したくなる。いろいろ調べてみた結果、見た目も含めて選んだのがCount per Day。自分の場合wordpressの運用は初めてではないので、何となく前も使ってたような。閉鎖する前に使っていたプラグインのリストをメモっておけばよかったな。... 続きを読む

wordpress刷新

何から話そうか。とりあえずはwordpress刷新した事でも。
見た目的にはテーマを変えただけなんだけど。
旧サイトから記事のデータはWordPressインポートツールを使って移植。
画像データは持ち込めなかったので、そこだけrsyncでコピー。... 続きを読む

サイト再構築

前回、ブログ復活と言いながらも結局続かなかった。理由ははっきりわからないが、つまるところ既存のサイトが飽きているのも1つ。そういう点の見直しも兼ねて、ここ半年くらいで自分の身の回りの後回しにしていた点を整理した。例えば、クレカや金融関連、インターネットや有料サービス系の取捨選択など。どれも物理的な手続きを必要とするものが多くて、ついつい先送りに。... 続きを読む

wordpressモバイル対応

本ブログへgoogleからの誘導が激減してから約一ヶ月、しばらくはPVの改善も見込めなそうなので、思い切って携帯対応してみた。携帯コンテンツであれば、また別の評価がなされるかもしれないし。どうやらwordpressのモバイル対応はプラグインによって簡単に実現できそうだ。今回は『Ktai Style』という評判の良いプラグインを使う事にした。いつも通りダウンロードして解凍したファイルを${WORDPRESS}/wp-content/pluginディレクトリに配置し、『プラグインの管理』画面でktai styleの欄で『使用する』をクリックする。... 続きを読む

wordpressのsitemap対応(後編)

先日のURL改変について、ほぼ全ての旧URLを新URLに301リダイレクトするように設定出来た。数日が経過した後、googleウェブマスターツールにて状況を確認してみる。しかし、残念ながらタイトルタグの重複数は減少していない。状況を正確に確認するためにアクセスログを見ながら、実際に旧URLをクリックしてみる。間違いなく新URLに転送されているが・・・、よく見てみるとリダイレクトのHTTPステータスコードが『302』になっている。ソースを確認し、『ylsy_permalink_redirect.php』ファイルの405行目を以下のように修正。... 続きを読む

wordpressのsitemap対応(前編)

前回のURL改変後より相変わらずPVが回復していない。今度はsitemap.xmlを作成して、検索エンジンに認識して欲しいURLを明示的に伝える事を試す。wordpressでsitemap.xmlを生成するには『google-sitemap-generator』を利用する。こちらよりプラグインをダウンロードしたら、いつも通りプラグインのディレクトリに配置する。wordpressの『プラグインの管理』ページより『Google XML Sitemaps』を有効化する。設定メニュー内にある『XML-Sitemap』にて必要な設定を行った後、『サイトマップを構築する』リンクをクリックすれば生成できる。... 続きを読む

wordpressのSEO対策

前回ユーザビリティの改善のために各文言の和訳や表示順の入替などを実施した。この変更は図らずもページタイトルのフォーマットにも及ぶ事になった。基本的にはPVを上げるための施策だったが、結論から言うとPVは激減した。正確な因果関係は不明だが、状況としてはgoogleの検索結果順序が大きく落ち込んでしまった。やはりgoogleのクシャミ一つでネット上でのポジションが大きく変わるというのは相変わらずのようだ。以前に運用していたサイトも、この手の問題でやる気がなくなって実質凍結状態にした事を思い出した。他の誘導パス作りをさぼっていたのがいけないんだけどね。... 続きを読む