「PHP」タグアーカイブ

既に運用中のCentOS 7.x上のZabbix(Webフロントエンド)のPHPを5系から7系に入れ替える

※2018/06/28 内容ブラッシュアップ

インストール時にCentOS 7.x系でPHP 7.xを使いつつZabbixを導入する方法はちょくちょく見かけるのですが、既に運用中で入れ替えて見る物は見かけなかったので残しておきます。PHP 5.6のサポート終了も年内となり、おそらくZabbix Webフロントエンドの動きもより快適になるであろう7.xに入れ替えていきましょう。

前提

CentOS Linux release 7.5
Zabbix 3.4.10
remiレポジトリから導入したPHP 5.6 → 同7.1
DBにはMySQLを利用

作業

・remiレポジトリの設定 /etc/yum.repos.d/remi.conf のPHP 5.6のenable設定を0に変更し、代わりに7.1を有効にします。

・このまま yum update php php-common を投げるとアップデート出来そうですが、実際には依存関係の絡みで失敗します。これはZabbix Webフロントエンドがphp-mysqlなるパッケージに依存している(事になっている)からなのですが、PHP 7.xにはもうそのようなパッケージはもう存在しません。本来php-mysqlndさえ存在していれば普通に動作します。

・--skip-brokenオプションで回避できそうなメッセージも表示されますがそれを試しても結果はそう変わりません。yumでの導入を諦めてZabbixのパッケージをrpmで直接インストールするなどが可能なのですが、裏技的に以下のような対応で回避できます。

・ yum update php php-common --exclude=php-mysql

・上記コマンドを実行するとphp-mysql導入をスルーし、代わりにremiレポジトリ内にあるpecl拡張となったphp-pecl-mysqlがインストールされます。これはメンテナンスの終わったphp-mysqlモジュールをpecl拡張としたものですが、これでお茶を濁す事でphp 7.xもzabbix-webもyumを利用してインストールした状態にすることができます。

・もっとも実際には利用しないモジュールとはいえ、保守の終わったセキュリティフィックスも当たらない拡張を入れておくのも気持ちが悪いので設定で無効化しておきます。

・/etc/php.d/50-mysql.ini 内でエクステンションを読み込んでいる部分をコメントアウトする事でphp-pecl-mysql拡張は読み込まれなくなります。これでyumでの導入状態を壊すことなく不要なエクステンションを無効化出来ます。

・zabbix-web-mysqlはmysqlモジュール(で提供されるmysql_* 関数)を利用していないので無効化してしまっても動作上全く問題は有りません(※1)。

なお、php.ini や /etc/httpd/conf.d/zabbix.conf 等の設定については今回触れませんので適宜調整してください。

※1: Zabbix 3.4が本当にphp-mysqlに依存していない事を確認してみた

CodeIgniter 3.x で作ったWebアプリを更に高速化させていく

この記事は CodeIgniter Advent Calendar 2017 の 12月16日分の投稿です。

CodeIgniter は元々軽量・軽快で高速なフレームワークですが、今時の高速化トレンドに対応して更に速くしていきましょう。

PHP 7に対応する

PHP 7.0 でも 7.1 でも 7.2 でも動きます！
もちろん PHP OPcache も有効にしておきましょう。更に速くなります。

gzip圧縮にする

Googleのアドバイスツールでも指摘してくるやつですね。CodeIgniter、というよりはPHPの標準的な機能になるのですが、以下のコード(冒頭4行)をビューのアウトプットをする前に入れておくだけでPHPの透過的なgzip圧縮が有効になります。簡単。

// 透過的な圧縮を有効にする
if (ini_get('zlib.output_compression') != 'On') {
	ini_set('zlib.output_compression', 'On');
}

$this->load->library('Twig');
$data = [
	'title' => 'XXXXXXX',
	'hoge' => $hoge,
	'foo' => $foo,
	'bar' => $bar
];
$this->output->set_output($this->twig->render('dir1/example', $data));

※このコードではビューの組み立てにTwigを使っています。

注意点として、画像であったりZIPファイルをバイナリで返したりであるような際に透過的な圧縮が有効になっているとファイルが壊れてしまったりします。そういう出力をするURLが有る場合は、全てのURLで常に適用されるような書き方は避けるのが無難です。

http/2対応にする

これはWebサーバ側の話になるのでもちろん CodeIgniter でも対応可能です。http/2 に対応したバージョンの Apache 2.4 or Nginx (h2oとかOpenLightSpeedとかでも)と php-fpm を組み合わせてあげましょう。Apache を http/2 に対応する場合、prefork MPMではなくevent MPM（やworker MPM）にする事が必要になりますので、その辺りも適宜チューニングしていきましょう。

参考： Amazon Linux AMI 2017.09で今こそApacheをhttp/2対応にする手順

APIのバックエンドとして同時に叩かれる

CodeIgniter 3は同じクライアントから同時に複数URLを叩かれるような場合に、同時に処理せず逐次処理のような挙動をします。これはPHPのセッションが有効になっている際の制限なのですが、セッションの機能を使い終わったタイミングでセッションを書き込み・クローズさせてあげる事で並列度が上がります。

// 同ユーザー・セッションからの連続アクセスの為にセッションのロックを解除する。
// これを実行した後はセッション関連の機能が使えない事に注意。
session_write_close();

そもそもAPIでセッションを利用しているのがよくないという話も有りますが、必要な場合にはこの対策をどうぞ。

Redisでキャッシュとかも使っていきたい

Memcachedとか、AWSのElastiCacheとか。CodeIgniterにはそれらを利用するための機能が標準で用意されています。……といっても私自身は php-pecl-redis で直接 Redis を扱ってしまっているのでCodeIgniter側の機能は使った事が無いのですが。ちょっと重めの外部APIから値を取得しているような場合など、適用できそうな場所はどんどん Redis でキャッシュしましょう。

RDBの冗長化はAmazon RDSが便利だよね

といっても一応フェイルオーバーには数十秒かかります。以下の過去記事で「数秒間のDB接続不可に耐えるための方法」をまとめてあります。

参考: CodeigniterのDB接続不可をハンドリングして再接続する

また、CodeIgniterのデータベース接続には「1つ目の接続先が繋がらなかった場合に2つ目の接続先に繋ぐ」という機能が有ります。これはまだ活用した事が無いのですが、MariaDB の Galera Cluster であったり、PostgreSQL の BDR (Bi-Directional Replication) など、これからのマルチマスター時代のフェイルオーバーに容易に対応出来ちゃったりするのでしょうか。出来るのかは分かりませんが、試してみると面白いかもしれません。

終わり

他にもいろいろあるかもしれませんがこの辺で。フロントエンドだと AMP 、 ServiceWorker など色々な話題が有ります(その辺も勉強しないとなぁ)が、CodeIgniterも高速化していきましょう。

CodeIgniter 3.xのログ出力をもっと便利にする

この記事は CodeIgniter Advent Calendar 2017 の 12月15日分の投稿です。
14日の記事は @NEKOGET さんの「CodeIgniter3のチュートリアルをリファクタリング(1)」でした。

CodeIgniter の良い所はやろうと思った事がほぼ素のPHPの知識だけでも実装してしまう事。誰でもさくっと作れてしまうので、小ネタ的な物はあまり見かけないような気がします。有っても数年前にほぼ同じような事を書いたブログ記事がもう有ったり。でも、ブログはいつか消える物。というわけで今回は CodeIgniter のログ出力をちょっと便利にしてみたいと思います。最新のｎ番煎じです。

ログを出力したクラスと関数名を自動で出力する。
おもむろに配列を放り込んでもそのまま中身を出力してくれる。
自分自身のコードから出力したログとフレームワーク自体のログを見分けられるようにする。

ファイル名: exlog_helper.php
Gistへのリンク（こちらの方が読みやすいかと）

&lt;?php
if (! function_exist('logDebug')) {

    function logDebug($message)
    {
        $trace = debug_backtrace();
        $output = 'UserLog: ' . $trace[1]["class"] . '::' . $trace[1]['function'] . ' - ';
        if (is_array($message)) {
            $message = print_r($message, true);
        }
        $output .= $message;
        log_message('debug', $output);
    }
}

if (! function_exists('logError')) {

    function logError($message)
    {
        $trace = debug_backtrace();
        $output = 'UserLog: ' . $trace[1]["class"] . '::' . $trace[1]['function'] . ' - ';
        if (is_array($message)) {
            $message = print_r($message, true);
        }
        $output .= $message;
        log_message('error', $output);
    }
}

debug_backtrace()で取得した結果を混ぜ込んでいるだけのログ出力ヘルパーです。渡された変数が配列だった場合はprint_rで文字列にしています。後はファイルの何行目で実行されたかも出しておきたい場合も添え字 ‘line’ に入っています。これをCodeIgniterのautoload対象helperとしておけば、どこでも利用可能になります。CodeIgniterで開発を始める前にこんな感じの機能を用意しておくと何かと便利です。やっている人はもうやっているのでしょうが、私はこんな風に書いているよーと共有までに。

CodeIgniterとは直接関係ないけども：
久しぶりにCodeIgniter以外のフレームワークを触ってみたら1年で死んでしまった話を書きました。→ https://www.sodo-shed.com/archives/12182

そど

urakuの作ったもの、作ろうとしているもの、作ろうとしていたものの近況。