ログイン



Archive for 2月, 2012

PHP5.4.0 RC8

2月 20th, 2012 by

うっかり見落としていましたが、2月15日にPHP5.4.0 RC8がリリースされていました。RC以降の修正点はかなり減ってきていますが、バッファーオーバーフローを引き起こす問題や、max_input_vars関連の調整などが入っており、5.4.0正式版のリリースまではしばらく掛かりそうな印象です。ほぼ2週間周期でRC版がリリースされているので、2月末頃にはPHP5.4.0 RC9もしくは、PHP5.4.0の正式版がリリースされるでしょう。

https://svn.php.net/repository/php/php-src/tags/php_5_4_0RC8/NEWS

15 Feb 2012, PHP 5.4.0 RC 8
– Core:
. Added ability to reset user opcode handlers (Yoram).
. Improved max_input_vars directive to check nested variables (Dmitry).
. Made ZEND_SIGNALS configurable via –enable-zend-signals, off by
default (Stas).
. Fixed bug #60965 (Buffer overflow on htmlspecialchars/entities with
$double=false). (Gustavo)

– CGI/FastCGI SAPI
. Fixed reinitialization of SAPI callbacks after php_module_startup().
(Dmitry)

PHP5.4のベンチマークまとめ

2月 18th, 2012 by

PHP5.4の正式版のリリースが迫ってきています。Trait、Short Array Syntacなど魅力的な機能も多数実装されていますが、そんな理由ではPHP5.4は絶対に導入できません。新機能を喜ぶのはプログラマであり、プログラマはPHPのバージョンの決定権などありません。PHPのバージョンを5.4に切り替えてもらうためには、サーバ管理チームや経営陣が喜ぶ理由が必要です。ということで、PHP5.4のパフォーマンスについての記事をまとめてみました。

1. PHP5.4 で Symfony2 は速くなるのか?

Synfonyのテストに掛かる時間と消費メモリ
PHP5.3.8 19.6秒 264.0MB
PHP 5.3.9RC2 19.0秒 191.5MB
PHP 5.4.0RC2 14.2秒 136.8MB

2割以上高速化しています。

2. チューニンガソンで優勝してきました

WordPress(ja) + php + Apache + MySQLの環境で、コメントの投稿速度を競ったところ、PHP5.4を使ったチームが優勝。優勝チーム曰く、PHP5.4を選んだことが勝因だったそうです。

3. PHP5.4のベンチマークが劇的に改善されている。

PHP + Zend OptimizerPlus performance [req/sec]
———————————————-
5.3 5.4 speedup
drupal 1074.3 1146.7 7%
zend framework 102.9 124.6 21%
wordpress 119.8 130.8 9%
xoops 78.4 93.0 19%

実アプリでも、10〜20%前後の性能向上を見込めそうです。

4. WordPress on PHP5.4.0 RC4 + APC

WordPressでベンチーマークを実行。APC無効では2割弱、APC有効では7割近くもスループットが向上しています!

5. PHP5.4.0RC7の実効速度

単純なループで実行速度を測定。PHP5.4.0RC7はPHP5.3.10より5割程度速いという結果に。

6. Performance improvements in PHP 5.4.0

WordPress(投稿が多数ある上に、プラグインも複数導入した状態らしいです)で測定したところ、PHP5.4.0beta1は、php5.3.5と比べて、実行時間が25%短縮され、消費メモリも43%削減されたそうです。

まとめ

PHP5.4は、PHP5.3系と比べて少なくとも9%、条件によっては7割程度の性能向上が見込めそうです。運用するソフトウェアによって性能向上の幅は異なりますが確実に性能が上がります。サーバの負荷がさがり、コスト削減につながります。

PHP5.3系と完全な互換性があるわけではありませんが、PHP5.4の魅力的な機能を使うためなら、プログラマ達は寝食を忘れてPHP5.4対応作業を行うでしょう。

PHP5.4.0RC7の実効速度

2月 7th, 2012 by

PHP5.4は速い。という情報が出ているので実際に測定してみた。

実行環境

EC2でc1.mediumを使って実験した。OSは32ビットで、PHPはコマンドライン(CLI)モードを使った。

ハードウェア

AmazonEC2 c1.mediumを使用。

CPUは以下のとおり。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 26
model name      : Intel(R) Xeon(R) CPU           E5506  @ 2.13GHz
stepping        : 5
cpu MHz         : 2133.306
cache size      : 4096 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse sse2 ss ht nx constant_tsc nonstop_tsc aperfmperf pni ssse3 sse4_1 sse4_2 popcnt hypervisor
bogomips        : 4266.61
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 26
model name      : Intel(R) Xeon(R) CPU           E5506  @ 2.13GHz
stepping        : 5
cpu MHz         : 2133.306
cache size      : 4096 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse sse2 ss ht nx constant_tsc nonstop_tsc aperfmperf pni ssse3 sse4_1 sse4_2 popcnt hypervisor
bogomips        : 4266.61
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

測定してみた

ループ1000万回に掛かる時間を10回測定
ソースコード

1
2
3
4
5
6
<?php
for($i = 0; $i < 10; $i++){
$start = microtime(true);
for($j = 0; $j < 10000000; $j++);
printf("%.5f\n", (microtime(true)-$start));
}

実行結果: PHP5.3.10
平均616ms

1
2
3
4
5
6
7
8
9
10
11
[root@ip-10-150-231-174 ec2-user]# php-5.3.10/sapi/cli/php bench.php
0.61347
0.61123
0.61310
0.61214
0.61255
0.61618
0.61851
0.61899
0.62268
0.61765

実行結果: PHP5.4.0RC7
平均:408ms PHP5.3.10比で1.51倍の実行速度

1
2
3
4
5
6
7
8
9
10
11
[root@ip-10-150-231-174 ec2-user]# php-5.4.0/sapi/cli/php bench.php
0.40750
0.40780
0.40873
0.40742
0.40734
0.40746
0.40784
0.40703
0.40780
0.40723

まとめ

掲載した以外にも何パターンかのベンチマークをとってみたが、いずれの測定結果でも実効性能は大幅に向上していた。既にRCまで開発が進んでいるので、正式版でもほぼ同じような性能特性になるだろう。性能面だけをとってみても、PHP5.4は価値のあるリリースになりそうだ。

PHP5.4.0 RC7

2月 6th, 2012 by

2012年2月2日に、PHP5.4.0 RC7が密かにリリースされていました。同じ日にPHP5.3.10リリースノートを見る感じでは、次にPHP5.4.0 RC8が控えており、RCの文字が取れるのは来月以降になりそうです。

RC7 ダウンロードページ
http://qa.php.net/

いつまでRCが続くか予想するのは難しいですが、春頃には正式版がリリースされ、運用に使われるのは2012年末頃ではないでしょうか。

CVE-2011-4885:ハッシュ衝突を悪用できる脆弱性

2月 5th, 2012 by

PHP5.3.9では、脆弱性CVE-2011-4885が修正された。この脆弱性を悪用すると、サーバに過度の負荷を掛け、サービスを提供できない状態にできます。この不具合はPHP5.0系、PHP5.1系、PHP5.2系にも含まれていますが、PHP5.3系以外の修正版は提供されていません。

セキュリティーホールの概要
 GETやPOSTで渡された変数はハッシュ構造に格納される。変数名に細工を加えることでハッシュの衝突が生じる。全ての変数のハッシュが衝突した場合、N個の変数の格納には、O(n2)の時間がかかるため、CPUに大きな負荷が発生する。

セキュリティーホールの修正
設定項目にmax_input_vars(デフォルト値1000)が追加された。計算量はO(n2)なので、1000個ぐらいの変数が衝突しても、現代のサーバなら問題ない。

バージョンアップせずに対応する方法
PHP5.3系を使っていれば、PHP5.3.10へのアップデートには大きなリスクはないが(とはいうものの、動作検証は必要)、PHP5.2系以前から、PHP5.3系への移行は一大事。DeprecatedやNoticeが大量に発生するだけならまだ良いが、関数名の衝突などが発生すると、アプリケーションのソースコードに手を加えざるを得ない。post_max_sizeに小さめの値(100kBなど)を設定すれば攻撃に対するリスクは軽減できる、ファイルのアップロードができなくなるなど、新たな問題が発生する可能性がある。現実的な対策としては、php.iniのpost_max_sizeを小さく設定し、ファイルのアップロードなどが必要な部分だけ、.htaccessを使って、post_max_sizeを適切な値に書き換えるのがよさそう。この対処をしても、ファイルのアップロード部分を攻撃されるとCPU負荷は上がるが、何も対処せずに、自動攻撃ツールの餌食になるよりはマシ。

とは言うもののバージョンアップしましょう
 上記の方法で、セキュリティーホールの穴を多少なりとも小さくできるが、設定変更や、その後の動作検証など、煩わしい作業が発生してしまう。古いバージョンのPHP(に限らずあらゆるソフトウェア)には、既知の脆弱性が含まれいる。攻撃の餌食になる前に、計画的にアップデートできるよう、きっちりした運用体制を構築しておくことが重要。

【緊急パッチ】PHP 5.3.10 Released!

2月 4th, 2012 by

PHP5.3.10がリリースされました。このバージョンでは、リモートからの任意のコードが実行できるというセキュリティーホールが修正されています。

Fixed arbitrary remote code execution vulnerability reported by Stefan Esser, CVE-2012-0830.

PHPの公式サイトは、全てのユーザに対して、PHP5.3.10へのアップデートが強く推奨していますが、このセキュリティーホール自体はPHP5.3.9へのアップデートで発生したそうなので、PHP5.3.8以前であれば慌てて対応する必要はなさそうです。

  • You are currently browsing the PHP6.jp blog archives for 2月, 2012.