皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

昨日、『CDNが効果的か否かの実証実験』という記事にてCDNを改めて検証した結果をお伝えいたしましたが、その際、WordPressを使用している場合のPHP設定に注意したいことがあります。

CDNを使用したWordPressのPHP設定

CDNを使用している場合のWordPressにおいて、PHPの設定で少々問題が生じるものがあります。

以前、『WordPress更新で注意する.ini』でご紹介した『output_handler』に『ob_gzhandler』を用いた場合です。

これ、CDNを使用していない場合においてもWordPressの本体やプラグインの更新で『更新が止まっているように見える』という現象を引き起こしていたものですが、現在の『WordPress 5.0』以降では現象が起きない状態に戻っています。

ただし、『WordPress 5.0』以降であっても『WordPress 4.7』、『WordPress 4.8』、『WordPress 4.9』あたりの時のように現象が起こってしまうことがあります。

それが『CDNを使用している時』です。

これが『php.ini』、『.htaccess』、『httpd.conf』、『.user.ini（PHP5.3以降の場合）』で設定されている場合はコメントアウトするなどして対処されれば現象は起きないと思われます。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

冒頭に書いた記事を投稿したのが『WordPress 4.6』あたりの時ですが、その後の『WordPress 4.7』や『WordPress 4.8』以降においてアップデート更新時に『更新が止まっているように見える』現象を引き起こすものがありそうです。

WordPress更新で注意するディレクティブ

さて、今回新たにWordPressのアップデート更新にて『更新が止まっているように見える』現象を引き起こす可能性のあるものですが、それは『output_handler』に『ob_gzhandler』を用いた場合です。

『output_handler』は『スクリプトの全ての出力を関数にリダイレクトすることができる』もので、モード的には『PHP_INI_PERDIR』になるため、『php.ini』、『.htaccess』、『httpd.conf』、『.user.ini（PHP5.3以降の場合）』で設定可能なものです。

このディレクティブに『ob_gzhandler（出力バッファをgzip圧縮するためのもの）』という値を指定していた場合に『更新が止まっているように見える』現象を引き起こす可能性があります。

これは、特定のWordPressバージョンにおいてしか起こらない可能性もあります。

『WordPress 4.7』、『WordPress 4.8』、『WordPress 4.9』あたりは現象が起こる可能性が高い感じがしますが、『WordPress 5.0』以降においては現象が起こらない、問題が発生しない状態に戻っている可能性が高いと思われます。

ご参考までに。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

さて、今日は数日前にご紹介したPHP5.6系のパフォーマンス改善の続きです。

前回はPHPのコア部分に関するチューニングでしたが、今日は拡張機能部分に関してご紹介します。

PHP5.6系のパフォーマンスチューニング２

前回のコア部分では、以下の3つのことに関して触れました。

１．『output_buffering』

２．『memory_limit』

３．『replath_cache_size』

これにプラスαで、『OPcache』や『APCu』が使える（編集可能）のであれば、それも使ってみると良いです。

では、『OPcache』から。

『OPcache』が使える（編集可能）場合、以下のようにphp.ini（.user.ini）を編集してみてください。

※　他のシステムに影響を与えないようにしたい場合、可能な限り『.user.ini』を作成し、そこに記述することで全体への適用を避けられます。ただし、『PHP_INI_SYSTEM』項目はphp.iniでしか変更できません。また、サーバシステム側で制御されている場合には変更できません。

zend_extension = /path/opcache.so（例です）

opcache.enable = 1

opcache.enable_cli = 1

opcache.memory_consumption = 128

opcache.interned_strings_buffer = 8

opcache.max_accelerated_files = 4000

opcache.revalidate_freq = 60

opcache.fast_shutdown = 1

次に、『APCu』が使える（編集可能）場合、以下のようにphp.ini（.user.ini）を編集してみてください。

extension = /path/apcu.so（例です）

apc.enabled = 1

apc.enable_cli = 1

apc.shm_size = 64M

以上のような感じになります。

ただし、これらはCGI版（FastCGI版）での書き方になりますが、サーバがモジュール版PHPを採用しているのであれば『PHP_INI_SYSTEM』項目が大半ですので、.htaccessでの対応は不可となります。

つまり、モジュール版PHPが採用されている場合、サーバシステム側での設定のままということになります。

＜参考＞

『OPcache』は高性能なPHPアクセラレータで、パフォーマンスを向上させます。

『APCu』はユーザーキャッシュ機能を持ち、翻訳処理などの最適化処理に役立ちます。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

少し前に、『PHP7.2系のパフォーマンス他』という記事ではPHP7.2系のパフォーマンスなどに触れ、『EC-CUBE2.13系のPHP7対応』という記事ではEC-CUBE2.13系のPHP7対応が未だ開発者向けのαバージョン状態であることに触れました。

では、PHP5.6系ではパフォーマンス面を諦めるしかないのでしょうか？

PHP5.6系のパフォーマンスチューニング

PHP5.6系とは言え、まだ諦める必要はありません。

それなりにチューニングしてあげることによってある程度パフォーマンスは向上します。

まず、php.ini（.user.ini）を以下のようにしてみてください。

※　他のシステムに影響を与えないようにしたい場合、可能な限り『.user.ini』を作成し、そこに記述することで全体への適用を避けられます。ただし、『PHP_INI_SYSTEM』項目はphp.iniでしか変更できません。また、サーバシステム側で制御されている場合には変更できません。

１．『output_buffering』の値を『On』もしくは『4096』としてみてください。

例：output_buffering = On（output_buffering = 4096）

２．『memory_limit』の値をデフォルトの『128M』より大きくしてみてください。

例：memory_limit = 1280M

３．『replath_cache_size』の値をデフォルトの『16K』より大きくしてみてください。

例：replath_cache_size = 4096K

これらはCGI版（FastCGI版）での書き方になりますが、サーバがモジュール版PHPを採用しているのであれば、.htaccessに記述することで対応可能です。

ただし、『PHP_INI_SYSTEM』の場合は.htaccessでの対応はできません。

１の例：php_flag output_buffering On（php_flag output_buffering 4096）

２の例：php_value memory_limit 1280M

３：.htaccessでの対応不可

これ以外に『OPcache』、『APCu』が使え、その設定が変更可能なサーバを使われているのであればまだプラスαがありますので、後日改めてご紹介したいと思います。

これにより、PHP7.1系以前と比較してパフォーマンスなどはどう改善されたのでしょうか？

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

以前、『PHPを使う際のレンタルサーバ』と、『PHP7.1でパフォーマンス向上』という記事にて、PHPのパフォーマンスの改善に関して触れたと思います。

では、現在の最新系であるPHP7.2系はどれほどの改善がなされたのでしょうか？

PHP7.2系のパフォーマンス改善など

少々前置きしますが、昨今、Googleが発表している通り、ウェブのパフォーマンス（表示スピード）は検索ランキングに影響します。

デスクトップに限らず、2018年7月からはモバイル検索のランキングにも影響します。

そして、ウェブサイトにおいて非常に多く使われているCMSのWordPressはPHPで作られており、それで動作します。

また、エンジニアであれば他の機能改善などに目を向けるでしょうが、そうでなければ気になるのはパフォーマンスくらいでしょう。

さて、PHP7.2系（現在の最新バージョンは7.2.4）はPHP7.1系（現在の最新バージョンは7.1.6）と比べてどれくらいパフォーマンス改善がなされたのか？

いくつかのインターネット記事を読むと、『約10%程度の改善』と書かれています。

これ、実際にいくつかの測定サイトで計測してみると、変化が見られた測定サイトでも極わずかで、体感的には『微妙に変わっただろうか？』というくらいに思えます。

ただし、WordPress4.9.5（現在の最新バージョン）でデバッグモードで動作確認をしてみると、PHP7.1系で出ていた非推奨の警告がPHP7.2系では大幅に減少します。

これは、現在のWordPressの推奨環境が『PHP version 7.2 or greater.（PHP7.2以上）』となっていることから、PHP7.1系までで非推奨となっていたものの書き方を改善したのでしょう。

そして現在のPHP7.2系においても推奨されなくなる機能はいくつかあります。

・クオートしない文字列

・png2wbmp()およびjpeg2wbmp() 関数（次のメジャーバージョンアップで削除予定）

・INTL_IDNA_VARIANT_2003 バリアント（次のメジャーバージョンアップで削除予定）

・__autoload() メソッド

・php.ini の track_errors および $php_errormsg 変数

・create_function() 関数

・php.ini の mbstring.func_overload

・(unset) キャスト

・第二引数を指定しないで parse_str() 関数を使う

・gmp_random() 関数

・each()関数

・assert()関数に文字列を渡す

・エラーハンドラの $errcontext 引数

・read_exif_data() 関数

というように掲載されています。

結論から言えば、パフォーマンスに関しては PHP7.2.x ≒ PHP7.1.x 、他の要素も含めて考えると、PHP7.2.x ≧ PHP7.1.x（PHP7.2系がお勧め） といった感じでしょうか。