Tag Archives: php

密かに php 5.5.0

密かに VS 2012 update2 で PGO ビルドして使ってますが、体感速度的に早くなってる感じがします。実際 WP のページ生成時間も 0.6 sec 程度で 0.2 ~ 0.3 sec 程速くなってるようですし。

が、OPcache を有効にすると数時間後に Apache が妙なエラー出して落ちる現象が何度かありました。

AH00526: Syntax error on line 115 of (略)/Apache2/conf/extra/httpd-mpm.conf:
Invalid MaxMemFree value: 2048

Syntax error なら起動時に落とせよというか、今まで何の問題も無かったのに何なんでしょうね。MaxMemFree を設定して落ちにくくなる話は聞くけど、設定して落ちるってどうもメモリ周りの相性が怪しい気はするのですが。

xCache 3.0.3 は 5.5.0 にまだ未対応らしくビルド失敗しますね。無くても OPcache で十分速いので要らなさそうだけど。

Zend Optimizer Plusと一緒にPHPをPGOビルドすると謎の失敗

php 5.4.15 と Zend Optimizer Plus を一緒にビルドすると、何故か php_mbstring を境に pgd ファイルが作成されなくなるという謎の事象が起きていてどうしたものかと。

Win64 環境 (Windows Server 2012R2) 上の VC10 だから、ってわけでもないと思うのですが、試しに Zend Optimizer Plus を外すとちゃんと pgd ファイルが作成されるのでどう見ても犯人はこれだよなあと。MAKEFILE に問題が起きてるのかとも思いましたがそんなこともなく、pgd ファイルが作成されないエクステンションを個別にビルドしてもやはり作成されない。

これはこれでどうにも気持ち悪いので素直に外してビルドすべきかこれは。

ZendOptimizer Plus のビルド

あれ、結局 ZendOptimizer Plus の PHP 5.5 への統合って承認されたの? みたいな話を今頃知ったので、GitHub に上がっていたコードを確認を兼ねてビルド。

VC10 x64 と php 5.4.14 のビルド環境でもあっさり成功。

buildconf --add-modules-dir=../ext/
configure --disable-all --enable-object-out-dir=. --enable-debug-pack --enable-cli --enable-opcache
nmake.exe /nologo php_opcache.dll

パフォーマンスに有意な差があるかは別途確認で。W3TC が対応してからでも良い気はしてますけど。

php 5.4.13 64 bit ビルドの再挑戦

色々実験したので整理を兼ねたメモ。

  • VC9 でビルドしないと一部の拡張 (ICU や gettext) がリンク出来ずビルドに失敗する
  • しかし VC9 で 64 bit ビルドしても APC は動作が怪しい (php-cgi -i でエラーが出る)
  • VC9 で PGO ビルド (インストルメント生成) するとリンカがメモリ 400 M 喰ったあたりで固まる
  • VC10 だと普通に成功
  • VC11 はまだ未サポート (configure.js を書き換えてコンパイラを認識させて、MAKEFILE の LDFLAGS の version 表記修正しないと止まる)

PGO ビルドが止まるのはクロスコンパイル環境だからかなあという気もするのですが 64bit の方に VC 環境作るのはちょっと面倒すぎて。

PGO ビルドした方が実行速度が速くなるのは実験で確認済みなので、ここは素直に VC10 でビルドするしか無いかなと。どうせ APC は動作が怪しいのだし、ICU なんて日本語環境じゃ全然使わないし。

あと 32 bit 環境で 64bit バイナリをビルドする場合、nmake snap してしまうと 64 bit バイナリの php が実行出来ずに止まってしまうのでファイルを下記のように修正するか他のオプションを使う必要があります。

  • MAKEFILE の mkdist.php 実行部分の php.exe を 32bit php のパスに書き換え
  • ソース win32/build/mkdist.php にある deplister.exe 実行パス格納変数 $cmd を 32bit でビルドした deplister.exe のものへ書き換え

64 bit な開発環境が無いと面倒臭いですね、やっぱり。

XCacheのconfigureオプション

ふと、32bit 環境の php に公式配布の XCache を入れて php -v して違和感に気付きました。

PHP 5.4.9 (cli) (built: Nov 21 2012 19:54:46)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
    with XCache v3.0.0, Copyright (c) 2005-2012, by mOo
    with XCache Cacher v3.0.0, Copyright (c) 2005-2012, by mOo
    with XCache Coverager v3.0.0, Copyright (c) 2005-2012, by mOo

XCache Coverager とか自分でビルドしたやつだと出ないよ? ということで調べてみたらどうやら普通に configure オプションの問題でした。

Coverager は –enable-xcache-coverager 付けときゃ良いようです。が、help みると他にも色々あるので付けてみたところ、エラー無しでビルドできたのはこんな感じ。

cscript.exe /nologo configure.js --disable-all --enable-object-out-dir=. --enable-debug-pack --enable-cli --enable-xcache=yes,shared --enable-xcache-optimizer --enable-xcache-coverager --enable-xcache-encoder --enable-xcache-decoder --enable-xcache-disassembler

このうち –enable-xcache-optimizer は付けないとオプティマイザが動かないって事かと焦りましたが、FAQ 読むとそもそも 3.0 では実装されていないようで。

1.15. I have read that xcache.optimizer setting gives an important performance gain. is that true ?

Currently only the “cacher” and “coverager” modules are implemented, tested and known to be working, the “optimizer” does **nothing**. it will be available only in XCache version 2, which is in an early development stage.

試しに –enable-xcache-optimizer の有無でビルドしてみましたが、特に有意なパフォーマンス差が出るわけでも無いので現時点ではやはり意味なさげ。

ということで、普通に使う分には –enable-xcache=yes,shared で cacher が有効なら問題ないのでしょう。

Windows版phpをビルドするためのライブラリを新しく

よくよく探してみたら、ちゃんと github に Windows 向け php をビルドするのに必要なライブラリの一部が上がってました。

ということでライブラリ最新化の現状。

  • ICU v50.1 NG
  • gettext v0.18 OK
  • libiconv v1.14 OK
  • libpng v1.5.13 OK
  • libxslt v1.1.27 OK
  • cURL v7.28 OK

ICU は相変わらずダメですね。上記 github にあった 49.1.2 をビルドしてもリンク時に失敗します。何でしょうこれ。

libiconv 1.14 は github のをビルドしただけであの苦労は何だったんだという位にあっさり成功。日本語圏の php じゃ殆ど使われてないので正直どうでも良かったのですがこれで多少すっきりしました。

cURL 7.28 は ENABLE_WINSSL を付けてやるとビルド成功、忘れると失敗になる謎動作でした。

nmake /f Makefile.vc mode=static VC=10 WITH_SSL=dll WITH_ZLIB=dll WITH_SSH2=dll WITH_DEVEL=../../../DEPS MACHINE=x64 ENABLE_WINSSL=no

上記 github の 7.27 をビルドすると SPNEGO が disable 、本家 7.28 だと enable になるようなので一応 7.28 採用で。

gettext は phpinfo() でもバージョン出てこないので意味あるのかよくわかりませんが、とりあえず新しいのに越した事は無いかなと。

あと enchant とかも上がっていますが、面倒そうなので後回しで。

cURLはともかくICUがダメダメ

php 64bit 自前ビルドのライブラリを (略) 計画の続き。

cURL 7.28 はどうやら OpenSSL ではなく WINSSL を使うようにしてやると nmake が通るっぽいです。そのまま php のビルドも問題なし。WINSSL ってなんだよそれという不安だけが気がかりですが。

一番簡単だと思っていた ICU は 48.1.1 以外は認めないという勢いなのか新しい 49 や 50 に入れ替えると php のビルド途中で止まります。しかも具体的に何が原因なのかもよくわからないと。これが一番困るというのに。

libiconv 1.14 のビルドで躓く

php ビルド時のライブラリを最新版にしよう計画、実はあっさりいけるんじゃないかと期待したlibiconv 1.14 であっさり難航。

libiconv は公式には VC でのビルドをサポートしなくなったため、How to Build libiconv with Microsoft Visual Studio の手順でちゃんとビルドされることを確認しています。ただこの手順は dll をビルドするものだというぐらいで。

素人考えで、dll ではなくスタティックライブラリをビルドするように VC の設定を変えりゃできるんじゃね、と買えたら確かに .lib ができてはくれました。

が、こいつで php をビルドすると外部参照 libiconv_set_relocation_prefix を解決できず止まってしまいます。

まさかと思って dumpbin してみると、1.11 だと libiconv_set_relocation_prefix がある。

dumpbin /headers iconv.lib | findstr "libiconv"
         COMDAT; sym= libiconv_set_relocation_prefix
         COMDAT; sym= $pdata$libiconv_set_relocation_prefix
         COMDAT; sym= $unwind$libiconv_set_relocation_prefix
         COMDAT; sym= libiconv_relocate
         COMDAT; sym= $pdata$libiconv_relocate
         COMDAT; sym= $unwind$libiconv_relocate
         COMDAT; sym= libiconv_open
         COMDAT; sym= $pdata$libiconv_open
         COMDAT; sym= $unwind$libiconv_open
         COMDAT; sym= libiconv
         COMDAT; sym= $pdata$libiconv
         COMDAT; sym= $unwind$libiconv
         COMDAT; sym= libiconv_close
         COMDAT; sym= $pdata$libiconv_close
         COMDAT; sym= $unwind$libiconv_close
         COMDAT; sym= libiconvctl
         COMDAT; sym= $pdata$libiconvctl
         COMDAT; sym= $unwind$libiconvctl
         COMDAT; sym= libiconvlist
         COMDAT; sym= $pdata$libiconvlist
         COMDAT; sym= $unwind$libiconvlist

しかし 1.14 の lib には libiconv_set_relocation_prefix がない。

dumpbin /headers libiconv.lib | findstr "libiconv"
Dump of file d:\php\tmp\new_lib\libiconv.lib
         COMDAT; sym= libiconv_open
         COMDAT; sym= $pdata$libiconv_open
         COMDAT; sym= $unwind$libiconv_open
         COMDAT; sym= libiconv
         COMDAT; sym= $pdata$libiconv
         COMDAT; sym= $unwind$libiconv
         COMDAT; sym= libiconv_close
         COMDAT; sym= $pdata$libiconv_close
         COMDAT; sym= $unwind$libiconv_close
         COMDAT; sym= libiconv_open_into
         COMDAT; sym= $pdata$libiconv_open_into
         COMDAT; sym= $unwind$libiconv_open_into
         COMDAT; sym= libiconvctl
         COMDAT; sym= $pdata$libiconvctl
         COMDAT; sym= $unwind$libiconvctl
         COMDAT; sym= libiconvlist
         COMDAT; sym= $pdata$1$libiconvlist
         COMDAT; sym= $chain$1$libiconvlist
         COMDAT; sym= $pdata$0$libiconvlist
         COMDAT; sym= $chain$0$libiconvlist
         COMDAT; sym= $pdata$libiconvlist
         COMDAT; sym= $unwind$libiconvlist

はて、一体何処で libiconv_set_relocation_prefix が抜けてしまったんだろう。1.11 についていた makefile.msvc の中身に秘密があるのかなあ……。

遅れて気付く

7 月から更新が止まっていたサイトで、無事 PHP 5.4.8 64bit が配布されていたようで。VC9 でのビルドだけどちゃんと最新のライブラリを使ってますね。自分のも新しいライブラリに入れ替えればできるのかなーと思って試してたりしてますが、そう簡単な話じゃなさそうなので困りますね。

そもそも PHP がオフィシャルにサポートしてる Windows のビルド環境は VC9 だという話は有りますが、だからこそ VC10 で挑みたいものです。

それにきっと VC9 より VC10 でビルドした方が最適化されてて速いよ、コンマ何秒かは、みたいなことがあるかもしれないので、有意な差が起こり得るのかは確認してみたいところです。

php 5.4.8 64bit Windows 自前ビルドのライブラリについて

基本的に新しいものを使用しているため、公式配布のものとは微妙にバージョンが違います。

Lib php v5.4.8 32bit php v5.4.8 64bit
BZip2 1.0.6, 6-Sept-2010 1.0.6, 6-Sept-2010
cURL 7.24.0 7.26.0
ZLib 1.2.5 1.2.7
libSSH libssh2/1.3.0 libssh2/1.4.2
libxml 2.7.8 2.8.0
FreeType 2.4.3 2.4.10
libJPEG 6b 8
libPNG 1.2.46 1.5.12
iconv 1.14 1.11
libXML 2.7.8 2.8.0
OpenSSL 0.9.8x 10 May 2012 1.0.1c 10 May 2012
libxml2 2.7.8 2.8.0

iconv だけは 1.11 なので、1.14 でビルドできるかはまた試したいところ。