The other answers address SAPIs implementations, and while this is relevant the question asks the difference between the thread-safe vs non thread-safe distributions.
First, PHP is compiled as an embeddable library, such as libphp.so on *NIX and php.dll on Windows. This library can be embedded into any C/CPP application, but obviously it is primarily used on web servers. At it’s core PHP starts up in in two major phases, the module init phase and then request init phase. Module init initializes the PHP core and all extensions, where request init initializes PHP userspace — both native userspace features as well as PHP code itself.
The PHP library is setup to where the module phase only has to be called on once, but the request phase has to be reinitialized for each HTTP request. Note that CLI links to the same library as mod_php ect, and still has to go through these phases internally even though it may not be used in the context of processing HTTP requests. Also, it’s important to note that PHP isn’t literally designed for processing HTTP requests — most accurately, it is designed for processing CGI events. Again, this isn’t just php-cgi, but all SAPI/applications including php-fpm, mod_php, CLI and even the exceedingly rare PHP desktop application.
Webservers (or more typically SAPIs) that link to libphp tend to follow one of four patterns:
- create a completely new instance of a PHP per request (old CGI pattern, not common and obviously not recommended)
- create one PHP instance, but go though both initialization phases (together) in separate forked child processes
- create one PHP instance, do module init once in parent process pre-fork, and then the individual request phase post-fork per HTTP request
Note that in examples 2 and 3 the child process is typically terminated after each request. In example 2 the child process must be terminated at the end of each request.
The forth example is related to threaded implementations
- call module init once in main thread, then call request init within other threads.
In the threaded case, request handling threads tend to utilize a thread pool, with each thread running in a loop initializing the request phase at the beginning and than destroying the request phase at the end which is more optimal than spawning a new thread per request
Regardless of how threaded implementations utilize libphp, if the module phase is initialized in one thread and request phases are called in different threads (which is the case PHP was designed for) it requires a non-trivial amount of synchronization, not just within the PHP core, but also within all native PHP extensions. Note that this is not just a matter of a “request” at this point, but synchronization that it being called on per PHP OPCODE that relies on any form of resource within the PHP core (or any PHP extension) which exists in a different thread as PHP userspace.
This places a huge demand on synchronization within thread-safe PHP distributions, which is why PHP tends to follow a «share nothing» rule which helps minimize the impact, but there is no such thing as truly «sharing nothing» in this pattern, unless each thread contains a completely separate PHP context, where the module phase and request phase is all done within the same thread per request which is not suggested or supported. If the context built within the module init phase is in a separate thread as the request init phase there will most definitely be sharing between threads. So the best attempt is made to minimize context within the module init phase that must be shared between threads, but this is not easy and in some cases not possible.
This is especially true in more complicated extensions which have their own requirements of how a their own context must be shared between threads, with openssl being a major culprit of of this example which effectually extends outward to any extension that uses it, whether internal such as PHP stream handlers or external such as sockets, curl, database extensions, etc.
If not obvious at this point, thread-safe vs non thread-safe is not just a matter of how PHP works internally as a “request handler” within an SAPI implementation, but a matter of how PHP works internally as an embedded virtual machine for a programming language.
This is all made possible by the TSRM, or the thread safe resource manager, which is well made and handles a very large amount of synchronization with little perceived overhead, but the overhead is definitely there and will grow not just based on how many requests per second that the server must handle (the deciding factor on how may threads the SAPI requires), but also by how much PHP code is used per request (or per execution). In other words, large bloated frameworks can make a real difference when it comes specifically to TSRM overhead. This isn’t to speak of overall PHP performance and resource requirements within thread-safe PHP, but just the additional overhead of TSRM itself within thread-safe PHP.
As such, pre compiled PHP is distributed in two flavors, one built where TSRM is active in libphp (thread-safe) and one where libphp does not use any TSRM features (non thread-safe) and thus does not have the overhead of TSRM.
Also note that the flag used to compile PHP with TSRM (—enable-maintainer-zts or —with-zts in later PHP versions) causes phpize to extend this outward into the compilation of extensions and how they initialize their own libraries (libssl, libzip, libcurl, etc) which will often have their own way of compiling for thread-safe vs non thread-safe implementations, i.e their own synchronization mechanisms outside of TSRM and PHP as a whole. While this not exactly PHP related, in the end will still have effect on PHP performance outside of TSRM (meaning on top of TSRM). As such, PHP extensions (and their dependents, as well as external libraries PHP or extensions link to or otherwise depend on) will often have different attributes in thead-safe PHP distributions.
The other answers address SAPIs implementations, and while this is relevant the question asks the difference between the thread-safe vs non thread-safe distributions.
First, PHP is compiled as an embeddable library, such as libphp.so on *NIX and php.dll on Windows. This library can be embedded into any C/CPP application, but obviously it is primarily used on web servers. At it’s core PHP starts up in in two major phases, the module init phase and then request init phase. Module init initializes the PHP core and all extensions, where request init initializes PHP userspace — both native userspace features as well as PHP code itself.
The PHP library is setup to where the module phase only has to be called on once, but the request phase has to be reinitialized for each HTTP request. Note that CLI links to the same library as mod_php ect, and still has to go through these phases internally even though it may not be used in the context of processing HTTP requests. Also, it’s important to note that PHP isn’t literally designed for processing HTTP requests — most accurately, it is designed for processing CGI events. Again, this isn’t just php-cgi, but all SAPI/applications including php-fpm, mod_php, CLI and even the exceedingly rare PHP desktop application.
Webservers (or more typically SAPIs) that link to libphp tend to follow one of four patterns:
- create a completely new instance of a PHP per request (old CGI pattern, not common and obviously not recommended)
- create one PHP instance, but go though both initialization phases (together) in separate forked child processes
- create one PHP instance, do module init once in parent process pre-fork, and then the individual request phase post-fork per HTTP request
Note that in examples 2 and 3 the child process is typically terminated after each request. In example 2 the child process must be terminated at the end of each request.
The forth example is related to threaded implementations
- call module init once in main thread, then call request init within other threads.
In the threaded case, request handling threads tend to utilize a thread pool, with each thread running in a loop initializing the request phase at the beginning and than destroying the request phase at the end which is more optimal than spawning a new thread per request
Regardless of how threaded implementations utilize libphp, if the module phase is initialized in one thread and request phases are called in different threads (which is the case PHP was designed for) it requires a non-trivial amount of synchronization, not just within the PHP core, but also within all native PHP extensions. Note that this is not just a matter of a “request” at this point, but synchronization that it being called on per PHP OPCODE that relies on any form of resource within the PHP core (or any PHP extension) which exists in a different thread as PHP userspace.
This places a huge demand on synchronization within thread-safe PHP distributions, which is why PHP tends to follow a «share nothing» rule which helps minimize the impact, but there is no such thing as truly «sharing nothing» in this pattern, unless each thread contains a completely separate PHP context, where the module phase and request phase is all done within the same thread per request which is not suggested or supported. If the context built within the module init phase is in a separate thread as the request init phase there will most definitely be sharing between threads. So the best attempt is made to minimize context within the module init phase that must be shared between threads, but this is not easy and in some cases not possible.
This is especially true in more complicated extensions which have their own requirements of how a their own context must be shared between threads, with openssl being a major culprit of of this example which effectually extends outward to any extension that uses it, whether internal such as PHP stream handlers or external such as sockets, curl, database extensions, etc.
If not obvious at this point, thread-safe vs non thread-safe is not just a matter of how PHP works internally as a “request handler” within an SAPI implementation, but a matter of how PHP works internally as an embedded virtual machine for a programming language.
This is all made possible by the TSRM, or the thread safe resource manager, which is well made and handles a very large amount of synchronization with little perceived overhead, but the overhead is definitely there and will grow not just based on how many requests per second that the server must handle (the deciding factor on how may threads the SAPI requires), but also by how much PHP code is used per request (or per execution). In other words, large bloated frameworks can make a real difference when it comes specifically to TSRM overhead. This isn’t to speak of overall PHP performance and resource requirements within thread-safe PHP, but just the additional overhead of TSRM itself within thread-safe PHP.
As such, pre compiled PHP is distributed in two flavors, one built where TSRM is active in libphp (thread-safe) and one where libphp does not use any TSRM features (non thread-safe) and thus does not have the overhead of TSRM.
Also note that the flag used to compile PHP with TSRM (—enable-maintainer-zts or —with-zts in later PHP versions) causes phpize to extend this outward into the compilation of extensions and how they initialize their own libraries (libssl, libzip, libcurl, etc) which will often have their own way of compiling for thread-safe vs non thread-safe implementations, i.e their own synchronization mechanisms outside of TSRM and PHP as a whole. While this not exactly PHP related, in the end will still have effect on PHP performance outside of TSRM (meaning on top of TSRM). As such, PHP extensions (and their dependents, as well as external libraries PHP or extensions link to or otherwise depend on) will often have different attributes in thead-safe PHP distributions.
Выбор версии PHP для Windows
Внимание! Данная статья безнадежно устарела или теперь оценивается автором, как не имеющая информационной пользы.
Прелесть open-source кода в его открытости :)) Т.е. при наличии ума/времени/желания можно разобраться, как именно работает программа. Обратная сторона такого кода — сложность в получении нужных скомпилированных пакетов. Например, PHP можно скачать в виде исходников для Nix-систем с последующей компиляцией/сборкой. Для Windows все уже собрано, но готовых бинарных пакетов много! Варианты с «thread safe/non thread safe«, VC6/VC9 и разные версии самого PHP. Статья создана для прояснения ситуации. В основе — разные источники, частично — перевод с английского. Все для того, чтоб в следующий раз мне опять не разбираться — «че к чему!?».
Нужная версия PHP зависит от версии веб-сервера, на котором он будет использоваться. Например, Apache 1.3.x работает с РНР версии 3.0.х, Apache 2.х работает с РНР версии 4.0 и выше. Но это не такая уж проблема, ориентируйтесь на более новые стабильные релизы и то, что стоит у хостера.
Что за приписки VC6, VC9, VC11? Исходники PHP под Windows компилируются в Visual Studio. VC9 получается при компиляции в VS 2008, VC11 — Visual Studio 2012. Соответственно, чтобы все это дело у вас работало, на компе должны быть установлены библиотеки Visual C++ Redistributable for Visual Studio соответствующего года. Некоторые разъяснения по этому поводу здесь.
Кроме того, если web-сервером у вас будет старенький Apache с сайта apache.org, то нужно качать VC6 версии PHP, для компиляции которых использовался Visual Studio 6. Если же PHP будет работать для IIS или в связке с более новым Apache, то можно собрать что-нибудь посовременнее 
Для меня главным ступором в выборе служит хостер. Сейчас есть стабильная версия PHP 5.5.4, а у него до сих пор 5.2.17!
Теперь самая интересная часть: «thread safe or non thread safe?«
Вольный перевод статьи Difference between PHP thread safe and non thread safe binaries (Dominic Ryan, 27.09.2007)
Я настолько ломанного английского еще не видел :(( Хотел по-быстрому перевести статью, но с трудом понимаю, что автор понаписал. Постоянные переходы между «what-is-that» и сложно-составные предложения вообще выносят мОСк. Перевод на русский так же осложняется тем, что у меня не хватает знаний и фантазии как правильно по-русски должно называться то, что обычно пишется только на английском %) Например техническое понятие «multi proccess architecture» я ни разу не видел на русском, а мой перл «потоко-небезопасные» вообще под вопросом здравого смысла. Вообщем, что получилось, то привожу.
Разница между thread safe и non thread safe бинарными пакетами PHP
С тех пор, когда PHP впервые появился под Windows 20 октября 2000 года в версии PHP 3.0.17, его бинарные пакеты всегда были собраны как потоко-безопасные (thread safe, TS). Основание следующее: Windows использует мульти-поточную архитектуру работы, а Nix-системы поддерживают мульти-процессовую архитектуру. Если PHP был скомпилирован как мульти-процессовое CGI-приложение вместо мульти-поточного, то его использование в качестве CGI-модуля под Windows на сервере IIS приводит к сильным тормозам и загрузке процессора. С другой стороны, можно подключить PHP на IIS, как ISAPI-модуль (требуется мульти-поточная сборка — прим. переводчика). Тогда возникает другая проблема:
некоторые популярные расширения PHP разработаны с ориентиром на Unix/Linux, т.е. с мульти-процессовой архитектурой, что приводит к краху PHP, подключенному на IIS в качестве ISAPI-модуля. Т.о. создание CGI — наиболее стабильная среда для PHP на IIS с основным недостатком, что это ужасно медленно. Приходится загружать и выгружать всю среду PHP из памяти каждый раз, когда есть запрос.
В то время было несколько вариантов для увеличения производительности PHP на IIS. Первый — использовать кеширование опкода программами типа eAccelerator, которые сохраняют PHP-скрипты в частично скомпилированном состоянии на диске и/или в памяти. Такой подход значительно сокращает время выполнения скрипта. Другой вариант заключался в настройке IIS на использование PHP в режиме FastCGI. При этом PHP-процесс после отработки не закрывался, а получал новое задание с очередным php-запросом. К тому же можно было запустить несколько PHP-процессов одновременно, ощутимо ускоряя обработку запросов, что являлось бонусом CGI-режима PHP. При этом могли быть незначительные проблемы с совместимостью PHP-расширений. Это по-прежнему самый быстрый способ использования PHP, и именно на задание такой конфигурации IIS настроен установщик «IIS Aid PHP Installer».
Бинарники, собранные в потоко-небезопасном режиме (non thread safe, NTS), позволяют сконфигурировать IIS (и другие веб-сервера под Windows) на использование PHP, как стандартный CGI-интерфейс с сильным приростом производительности, т.к. в этом случае (в такой сборке) PHP-процессу не нужно дожидаться синхронизации нитей. При сравнении работы «thread safe» и «non thread safe» бинарных пакетов PHP на IIS в качестве стандартного CGI-интерфейса прирост быстродействия составляет до 40%, но это все равно не так шустро как использование опкода в FastCGI методе. А самый большой косяк в том, что нельзя стабильно использовать потоко-небезопасные бинарники вместе с потоко-безопасными. Это значит, что вы не можете использовать системы кеширования опкода типа eAccelerator в среде PHP, созданной потоко-небезопасными бинарными пакетами (утверждение, верное на момент написания статьи).
Если потоко-небезопасный PHP нельзя сконфигурировать до такой же скорости, что и потоко-безопасную среду, то зачем он нужен в такой сборке? Возвращаемся к FastCGI и разработкам Microsoft в этой области за последние несколько лет. Кодеры мелкомягких создали свой вариант FastCGI, который позволяет конфигурировать потоко-небезопасные бинарники PHP в режиме FastCGI, что доводит производительность до скорости света 
—
Из статьи я сделал вывод, что тормоза наблюдаются только при использовании с веб-сервером IIS. В любом случае, тупняков под Windows+Apache я не видел. В ней же сказано, что можно разогнать NTS-сборку на любом веб-сервере, но я не представляю себе такой конфиг Apache.
[1oo%, EoF]
Понравилась статья? Расскажите о ней друзьям:
Здесь ответ на ваш вопрос.
Для тех, кто не знает английский.
Версию сервера нужно выбирать в зависимости от того, как вы интегрируете PHP c веб-сервером.
Например, когда вы используете mod_php, у вас модуль и PHP всегда загружены в память и каждый запрос обрабатывается в отдельном потоке. Из-за этого mod_php работает быстрее, чем CGI. В данном случае нужно использовать потоко-безопасную реализацию (thread-safe) поскольку каждый поток имеет доступ к памяти другого потока.
Когда вы работаете с IIS, у вас PHP запускается ввиде отдельного процесса через CGI и в таком случае потоко-безопасность не имеет смысла, поскольку у вас 1 процесс и фактически 1 поток созданный этим же процессом. Операционная система изолирует память процессов по умолчанию.
В случае модели с FastCGI, потокобезопасность также не имеет смысла, поскольку тотже PHP-FPM держит несколько отдельных процессов PHP в памяти, но не потоков.
After a lot of research, I’ve managed to find my own answers to this question.
In its most basic form, the answer is: What version of PHP you should install comes down what webserver you are running.
Here’s a deeper explanation of the terms used in picking a version of PHP based on what I learned:
VC6 vs VC9
Firstly, different versions of Apache for Windows are compiled with different compilers. For example, the versions on Apache.org are designed to be compiled using Microsoft Visual C++ 6, also known as VC6. This compiler is very popular, but also very old. (It dates back to 1998.)
There are different versions of Apache made for different compilers. For example, the versions available for download from ApacheLounge.com are designed to be compiled with the popular and more much recent compiler, Microsoft Visual C++ 9 from 2008. Also known as VC9.
(Note: These two compilers are the two most popular options. So while it’s possible to have a VC7, VC8, etc. compiled version of Apache, it’s unlikely that you’ll come across them.)
The use of this more recent compiler (VC9) is important because the latest versions of PHP are only being distributed in VC9 form (although older versions are still available for VC6).
On top of that, according to ApacheLounge there are numerous improvements when using a version of Apache compiled with VC9, «in areas like Performance, MemoryManagement and Stability».
If that wasn’t enough, the developers of PHP made the following statement on their site:
Windows users: please mind that we do
no longer provide builds created with
Visual Studio C++ 6 (VC6). It is
impossible to maintain a high quality
and safe build of PHP for Windows
using this unmaintained compiler.We recommend the VC9 Apache builds as
provided by ApacheLounge.All PHP users should note that the PHP
5.2 series is NOT supported anymore. All users are strongly encouraged to
upgrade to PHP 5.3.6.
In all, this is an extremely compelling argument to use VC9 versions of Apache and PHP, if you ask me.
So if you’re using a version of Apache from the official Apache site, it will be compiled with VC6, and as such, you should use the older version of PHP for that compiler. If you’re using a version of Apache compiled with VC9, like the one available on ApacheLounge.com, you can use the latest version of PHP (for VC9).
For me, running a local development environment, it would be preferable to have the latest version of PHP, so a VC9 version of Apache is required, so I can use the VC9 version of PHP.
Thread Safe vs Non Thread Safe
Once again this comes down to your webserver. By default Apache is installed on Windows as Module, but it can be changed to run as FastCGI. There’s plenty of differences between the two, but essentially FastCGI is more modern, faster, more robust, and more resource hungry. For someone running a local development environment, FastCGI might be overkill, but apparently lots of hosting companies run as FastCGI for the reasons I’ve stated, so there are good arguments for doing so in a development environment.
If you’re running Apache (or IIS) as FastCGI (or CGI) then you want the Non Thread Safe version of PHP. If you’re running Apache as default (as a Module), then you’ll want the more traditional Thread Safe version.
Please note: This all only applies to Windows users.
I’m not going to bother with FastCGI (unless someone convinces me otherwise), so for me, I want the VC9 Thread Safe version of PHP.
And that’s it.
Further reading:
- Official statement regarding PHP and VC6
- Difference between PHP thread safe and non thread safe binaries
- FastCGI at Wikipedia
- FastCGI for IIS
- Visual C++ at Wikipedia
- Compile your own PHP (explanation of VC6/VC9)