[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

PHP thread safety


Some time ago php4 packages enabled thread safety feature. I did the same for 
php5 packages. Now, I'm little confused after I've benchmarked php5 with zts 
and non-zts option:

The tests was made with apache2-prefork. The scripts were trivial 99bottles 
from well-known site and benchmarks/form/simple from WACT framework.

The results are counted as req/sec.


99bottles zts 309.18 - 296.69
99bottles non-zts 391.43 - 367.13
wact zts 59.98 - 56.01
wact non-zts 62.90 - 61.13

php5-fcgi + mod_fastcgi

99bottles zts 287.54 - 268.49
99bottles non-zts 316.17 - 297.09
wact zts 64.55 - 61.52
wact non-zts 74.70 - 70.30

I did not tested php4 but I suspected the results would be similar to php5. 

ZTS feature also makes an incompatibility with binary-only modules. See 
Bug#297679 or Bug#297223.

Of course non-ZTS version of PHP doesn't work in threaded environment like 
apache2-worker or caudium. At least these servers can cooperate with PHP 
through fastcgi.

What can we do:

1. Provide only ZTS version. This version is considered as experimental by PHP 
developers, gives a less performance (about 10%) and makes problems with 
commercial extensions provided only in binary form.

2. Provide only non-ZTS version. That means threaded webservers have to 
comunicate with standalone PHP binary through FastCGI. No more native support 
for caudium.

3. Provide both of them. The packages with extensions could 
contain /usr/lib/php5/20041030-zts and /usr/lib/php5/20041030 directory. The 
cgi, cli, apache and apache-prefork SAPI would be non-zts version. The 
apache-worker and caudium SAPI would be zts version. What about php5-dev 
package? Should provide i.e. /usr/bin/phpize5 and /usr/bin/phpize5-zts? The 
3rd-parties extensions could be compiled twice (for zts and non-zts) or ever 
4 times (for php4 and php5 in both flavours).

 .''`.    Piotr Roszatycki, Netia SA
: :' :    mailto:Piotr_Roszatycki@netia.net.pl
`. `'     mailto:dexter@debian.org

Reply to: