最近在 PHP 官网上看到又有新版的 PHP 下载了，于是上去找找 For Windows 的版本，可是一看确傻眼了，一共给了四个版本，VC9 x86 Non Thread Safe、VC9 x86 Thread Safe、VC6 x86 Non Thread Safe、VC6 x86 Thread Safe，这让菜鸟头疼啊，还好 PHP 官网提供下载的地方左边有个英文 choose 比较容易懂，估摸着就是如何来选择版本的意思吧，于是开始查字典及上网查找，终于看明白了具体意思，拿来做个备忘先。

一、如何选择 PHP 的 VC9 版本和 VC6 版本

VC6 版本是使用 Visual Studio 6 编译器编译的，如果你的 PHP 是用 Apache 来架设的，那你就选择 VC6 版本。VC9 版本是使用 Visual Studio 2008 编译器编译的，如果你的 PHP 是用 IIS 来架设的，那你就选择 VC9 版本。

二、如何选择 PHP 的 Thread Safe 和 Non Thread Safe 版本

先从字面意思上理解，Thread Safe 是线程安全，执行时会进行线程（Thread）安全检查，以防止有新要求就启动新线程的 CGI 执行方式而耗尽系统资源。Non Thread Safe 是非线程安全，在执行时不进行线程（Thread）安全检查。

再来看 PHP 的两种执行方式：ISAPI 和 FastCGI。

ISAPI 执行方式是以 DLL 动态库的形式使用，可以在被用户请求后执行，在处理完一个用户请求后不会马上消失，所以需要进行线程安全检查，这样来提高程序的执行效率，所以如果是以 ISAPI 来执行 PHP，建议选择 Thread Safe 版本；而 FastCGI 执行方式是以单一线程来执行操作，所以不需要进行线程的安全检查，除去线程安全检查的防护反而可以提高执行效率，所以，如果是以 FastCGI 来执行 PHP，建议选择 Non Thread Safe 版本。

Difference between PHP thread safe and non thread safe binaries

Submitted by Dominic Ryan on Thu, 2007-09-27 14:35.

Since the release of PHP 5.2.1 back in Feburary there has been two new binary packages available for Windows, the non thread safe PHP binaries and the non thread safe PECL binaries. Since then I've read many threads in Internet forums where there seems to be a bit of confusion on what these extra binaries are, how they are used, and what effect they have. In this article I'll discuss the pro's and con's of these new binaries.

Since PHP first came to Windows back on the 20th of October 2000 with the release of PHP 3.0.17, the Windows binaries have always been released as thread safe packages. The reason for this is that Windows uses a multi threaded architecture as opposed to the multi proccess architecture of Linux and Unix. The problem this has when using PHP on IIS in CGI mode is that it makes it very slow as CGI was built on a multi process model, not a multi threaded model. On the flip side the problem this has when using PHP on IIS with the much faster ISAPI module is that there are several popular PHP extensions that have been developed with only Unix/Linux in mind (multi proccess model), and actually cause the PHP ISAPI module to crash on IIS. This making CGI the most stable environment for PHP on IIS, with the major disadvantage that it is terribly slow due to it having to load and unload the entire PHP environment from memory everytime there is a request.

There have been a few options available for a while to get PHP performing well on IIS. Firstly is the use of an opcode cache such as eAccelerator which stores PHP scripts in a partically precompiled state on disk and/or memory which drastically decreases script execution time. Another option is to configure IIS to use PHP in FastCGI mode which allows PHP processes to be recycled rather than killed off after each PHP request and also allows you to run several PHP processes at once, making PHP much much faster with the added bonus that as it is using the CGI interface there is little or no incompatibility issues with PHP extensions. This is still the fastest way to serve PHP, and is the way the IIS Aid PHP Installer is configured to install PHP on your IIS Environment.

What the non thread safe binaries allow you to do is to configure IIS (and other Windows based webservers) to use PHP as a standard CGI interface with massively increased performance as the PHP process is not required to wait for thread syncronisation. The performance increase is not to be sneezed at either as I've seen figures of upto 40% mentioned (though I'm yet to confirm myself), but it is still not as fast as the opcode/FastCGI method mentioned above. One of the biggest catches I've seen people getting themselves hooked on is that non thread safe binaries cannot be reliably used with the thread safe ones, and vise versa. This means that (for the moment at least) you cannot use opcode cache systems such as eAccelerator to give your non thread safe PHP environment a boost in the arm as they are all currently compiled as thread safe.

If the non thread safe binaries are not as fast as what you can configure the thread safe binaries to be then what is the point you ask? Here we come back to FastCGI, and in particular the efforts Microsoft have been making over the last year or so with the development of their own FastCGI handler. This new FastCGI handler from Microsoft enables you to configure the non thread safe PHP binaries in FastCGI mode, which is one massive shot in the arm for performance. Easiest way to put it is using the non thread safe PHP binaries with Microsoft's new FastCGI handler is like putting twin turbos on your car (without the inherent risk of blowing up your engine), and there is little doubt in my mind that this will be the future of PHP on IIS.

• 杨超's blog
• 要发表评论，请先登录 或 注册