PHP FPM のチューニング

このサイトはNginx + WordPress で運用しているだが、設置当初はサイトが重くて仕方なかった。
top コマンドで状況を調べてみるとメモリを使い切っていたので、途方に暮れて解決策をググったところ、以下の記事を発見。 有用な記事をありがとうございました。

CentOS php-fpmの設定を変更してメモリ消費を減らした方法 | CrystalSnowman.com

サーバーはさくらのVPS (Cent OS 6、メモリ 1GB) なので、この記事とまさに同じ状況らしい。 これを参考に PHP FPM の設定 (/etc/php-fpm.d/www.conf) を以下のように変更し、現状運用中。

pm = dynamic
pm.max_children = 10 ; default 50
pm.start_servers = 5
pm.min_spare_servers = 2 ; default 5
pm.max_spare_servers = 6 ; default 35

設定変更前と比較にならないくらい軽く(というか普通に)なった。ここのようにアクセス数の少ないサイトはこういった設定で問題ないらしい。

PHP FPM はデフォルトで最大50ものプロセスを立ち上げようとするということは、比較的ハイスペックな環境を想定して設計されているのだろうか。果たして。

WP Pusher による WordPress テーマの自動デプロイ

WP Pusher というプラグインを導入し、GitHub のレポジトリの master ブランチに push したらサイトの WordPress テーマが自動的に更新されるという運用にしてみた。

seckie/likealunatic: Like@Lunatic website source code

サイトの静的ファイルがテーマディレクトリの外に散在していた状態だったから、それもできなかったわけだ。今回自作テーマを大幅に整理したことで、テンプレートも静的ファイルもすべて1つのテーマフォルダに収めることができた。(まあ当たり前の状態になったというべきか…)

GitHub の Webhooks による自動更新は以前からやりたかったのだが、CI ツールを使ったことのない僕にはハードルが高かった。しかし調べてみると、プラグインでそういうものがある、という情報があった ので導入してみることにした。該当記事の紹介によると、ビルドを Travis CI で行い、その後 dist ブランチに自動的にプッシュ、それを Webhooks で拾って本番にデプロイ、というフローになっている。しかし僕の環境だとビルドはローカルでやっているので Travis CI を使うフローは不要になる。シンプルに GitHub と WP Pusher だけの形で実現できた。

ただしハマったポイントが一つある。

WP Pusher は公式プラグインディレクトリに置いていないので、FTP を使ってアップロードした。すると、該当ファイルとディレクトリのオーナーは当然その FTP ユーザーになる。それによってパーミッションの問題が発生。

このサイトは Nginx + WordPress で動作している。 Nginx を使っている場合、wp-content ディレクトリなどに対して nginx ユーザーに書き込み権限を与えておけば、 WordPress (PHP) から自動更新やらプラグインの追加削除が行えるようになる。そうでない場合、WordPress は FTP 経由でファイルを出し入れしようとして FTP 情報を入力するプロンプト画面を表示する。
WP Pusher による自動デプロイも例外ではなく、パーミッションが適切でないと WordPress がそのページを表示しようとしてしまい、正しく通信できないらしい。

ちなみにエラーは GitHub の 該当 Webhook のページ下方に “Recent Deliveries” というセクションがあるのでそこで確認できる。 Webhook を設定すると通信確認のためなのか Recent Deliveries に1つ通信が記録される。それがエラーになっていた場合、Response が “500” となっているはず。Body のセクションを確認すると「FTP credentials を入力してください」という感じの HTML が出力されている。

GitHub Webhook setting screen
これは正常な状態。

今回のケースでは wp-content 以下すべてのファイル、ディレクトリオーナーを nginx ユーザーに変更したら解決した。 ちなみにこのことは WP Pusher Troubleshooting のページにもちらっと記述があった…。なんだろうこの徒労感。

参考

サイトのアップデート

直近の仕事が延期になってぽっかりと時間が空いたので、このサイトのメンテを一気にやった。

  • Bootstrap のアップグレード(v.1 -> v.3)
  • タスクランナーを Grunt から gulp に乗り換え
  • CSS プリプロセッサは Stylus から Sass (indented syntax) へ乗り換え
  • JavaScript は ES2015 + Babel を Webpack でビルドする環境へ
  • WordPress テーマディレクトリの整理
  • WP touch プラグインを廃止。スマホ向けスタイルは Bootstrap ベースで自作
  • WP Pusher による自動デプロイ

何年もサボっていたのでもう色々古かった。 Bootstrap はタイポグラフィーが格段に良くなりました。感心。それとモバイルファースト感が増していて、時代が移り変わった感じがします。 とはいえ今回使った v3.3.7 は2016年7月のリリースバージョンとなっていて、そんなに最新のトレンドっていう訳でもないです…。 というかこのリリースノートを見る限り Bootstrap ってもうあまり活発にメンテされていない感じか。

スティーブ・ヴァイ来日公演を見に行ってきた

The Story of Light Tour 2013 のTシャツ

昨晩は横浜ベイホールにスティーブ・ヴァイ来日公演を見に行って来た。

超絶ギターを弾きながら歌ったり踊ったり、ギターを振り回したり背中で弾いたり舌で弾いたり、メンバーと一緒になってLEDがビカビカに光る奇抜な衣装や演出をしたり、客をステージに上げて歌わせてその場でセッションしたり、とにかくオーディエンスを楽しませようという精神がすさまじくて、MCなどではお茶目でウィットに富んだトークをしてくれて、でもどこまでも謙虚で、自分の音楽を楽しんでくれるオーディエンスへの気配りと感謝を一時も忘れない。

そんな漢だった、Steve Vai という人間は。

彼は超絶ギタリストであるだけでなく、間違いなく極上のエンターテイナーであり、いつも観客の声援にニコニコと応える、素晴らしい人格者だった。

かつて10代の頃、誰にでも自分にとってのアイドルがいたと思う。彼らをライブコンサートなどで、実在する人間として実際に目の当たりにする興奮。この忘れていた興奮を、思い出した。

Steve は僕にとって間違いなくアイドルであり、彼が目の前に存在し、立ち居振る舞っていること自体に本当に興奮したし、人間離れした演奏とステージをこの目で見ることができた。 もう彼は50歳を超えているはずであるが、年齢を全く感じさせない、(ある意味いつも通りの?)エネルギッシュなステージを見せてくれた。 これが目の前で、現実として起こったことである。その事実にひたすら感動した。

彼がまた日本に来てくれることを、心から願わずにはいられないのである。

P.S.
また一つ嬉しかったのは、Steveがしゃべっていることが大体理解できたことだ。 自分の英語力は少しずつだが進歩している。ここ2年ほどやってきた英会話は無駄ではなかったようだ。

初めて pull request を体験するなど

最近、仕事で FuelPHP という PHP フレームワークを使う機会があります。いわゆる Cake PHP 的な MVC フレームワークで、PHP 5.3 以降対応としたことにより、今風に書かれているらしいです。

もう先月の話になるのですが、FuelPHP 1.6 翻訳ウィークというオンラインイベントを通じて、Fuel PHP 1.6 の日本語ドキュメントメンテナンスに参加しました。

翻訳作業には GitHub を通じて誰でも参加できるようになっており、初めて他人のプロジェクトに pull request を送るという体験をしました。日本語でやり取りができたので、はじめの一歩としては敷居が低かったと思います。

それにしても GitHub、やりとりのほとんどをブラウザ上で完結できてしまうほど、進化していたんですね。しかしこれだと git の勉強にはならないなー。