I didn’t want to hijack the Optimizer+ thread so I’m creating a new one,
based on the apparent level of interest in ZTS. This isn’t an RFC to
remove ZTS by any stretch, but I am a bit confused about why people are
still using ZTS.
A bit of background. I started the ZTS project (based on initial work by
Shane Caraveo more than a decade ago), and invested countless hours in
pushing it all throughout PHP. So I really hold absolutely no grudge
against it, quite the contrary… However, many years ago, I came to the
conclusion that it was a bit of a lost cause trying to weed out all the
thread safety issues from everywhere – and that a simpler, more elegant
solution exists in the form of FastCGI.
Which brings me to the subject of this mail – why are you using ZTS PHP
instead of single threaded PHP? The reasons not to use it are few but
fairly major – it’s significantly slower than the non-ZTS PHP, and it’s
significantly less robust in the sense that a single bug somewhere can
bring down an entire server (or at least a bunch of many different
threads). What are your reasons to choose it over FastCGI?
Zeev
I didn’t want to hijack the Optimizer+ thread so I’m creating a new one,
based on the apparent level of interest in ZTS. This isn’t an RFC to
remove ZTS by any stretch, but I am a bit confused about why people are
still using ZTS.A bit of background. I started the ZTS project (based on initial work by
Shane Caraveo more than a decade ago), and invested countless hours in
pushing it all throughout PHP. So I really hold absolutely no grudge
against it, quite the contrary… However, many years ago, I came to the
conclusion that it was a bit of a lost cause trying to weed out all the
thread safety issues from everywhere – and that a simpler, more elegant
solution exists in the form of FastCGI.Which brings me to the subject of this mail – why are you using ZTS PHP
instead of single threaded PHP? The reasons not to use it are few but
fairly major – it’s significantly slower than the non-ZTS PHP, and it’s
significantly less robust in the sense that a single bug somewhere can
bring down an entire server (or at least a bunch of many different
threads). What are your reasons to choose it over FastCGI?Zeev
Old behavior not easily to be changed.
let it as it be, all of us like to keep on old behavior as it was.
should put banner on php.net, say: do not using ZTS, that's old way.
--
Appreciate your time.
Netroby
Which brings me to the subject of this mail – why are you using ZTS PHP
instead of single threaded PHP? The reasons not to use it are few but
fairly major – it’s significantly slower than the non-ZTS PHP, and it’s
significantly less robust in the sense that a single bug somewhere can
bring down an entire server (or at least a bunch of many different
threads). What are your reasons to choose it over FastCGI?
I use it for long-running processes, when I need something like
http://pecl.php.net/package/pthreads
But, those are scenarios, when I don't need bytecode cache, because
everything is preloaded in "real" memory
--
Alexey Zakhlestin,
http://github.com/indeyets
I didn’t want to hijack the Optimizer+ thread so I’m creating a new one,
based on the apparent level of interest in ZTS. This isn’t an RFC to
remove ZTS by any stretch, but I am a bit confused about why people are
still using ZTS.A bit of background. I started the ZTS project (based on initial work by
Shane Caraveo more than a decade ago), and invested countless hours in
pushing it all throughout PHP. So I really hold absolutely no grudge
against it, quite the contrary… However, many years ago, I came to the
conclusion that it was a bit of a lost cause trying to weed out all the
thread safety issues from everywhere – and that a simpler, more elegant
solution exists in the form of FastCGI.Which brings me to the subject of this mail – why are you using ZTS PHP
instead of single threaded PHP? The reasons not to use it are few but
fairly major – it’s significantly slower than the non-ZTS PHP, and it’s
significantly less robust in the sense that a single bug somewhere can
bring down an entire server (or at least a bunch of many different
threads). What are your reasons to choose it over FastCGI?
Hey:
It's not we choose ZTS, it is there are many users run with them (IIS,
Apache+workers, and pthreads extension require it)
and all PHP extensions supports it, so if O+ doesn't, it feel a little
inconsistent.
thanks
Zeev
--
Laruence Xinchen Hui
http://www.laruence.com/
I didn’t want to hijack the Optimizer+ thread so I’m creating a new one,
based on the apparent level of interest in ZTS. This isn’t an RFC to
remove ZTS by any stretch, but I am a bit confused about why people are
still using ZTS.A bit of background. I started the ZTS project (based on initial work by
Shane Caraveo more than a decade ago), and invested countless hours in
pushing it all throughout PHP. So I really hold absolutely no grudge
against it, quite the contrary… However, many years ago, I came to the
conclusion that it was a bit of a lost cause trying to weed out all the
thread safety issues from everywhere – and that a simpler, more elegant
solution exists in the form of FastCGI.Which brings me to the subject of this mail – why are you using ZTS PHP
instead of single threaded PHP? The reasons not to use it are few but
fairly major – it’s significantly slower than the non-ZTS PHP, and it’s
significantly less robust in the sense that a single bug somewhere can
bring down an entire server (or at least a bunch of many different
threads). What are your reasons to choose it over FastCGI?Hey:
It's not we choose ZTS, it is there are many users run with them (IIS,
Apache+workers, and pthreads extension require it)and all PHP extensions supports it, so if O+ doesn't, it feel a little
inconsistent.
And, if O+ aims only to be a PECL extension, I think it's okey.
but if it is going to PHP src, I think the consistent should be
considered, agree?
thanks
thanks
Zeev
--
Laruence Xinchen Hui
http://www.laruence.com/
--
Laruence Xinchen Hui
http://www.laruence.com/
Hey:
It's not we choose ZTS, it is there are many users run with them (IIS,
Apache+workers, and pthreads extension require it)
For pthreads I can understand it, but why would users be using it on
IIS/Apache instead of using FastCGI? FastCGI is both faster and more
robust. Is it a matter of lack of knowledge, or is there a real reason to
use it?
and all PHP extensions supports it, so if O+ doesn't, it feel a little
inconsistent.
My question was outside the context of O+ - it should support it for as long
as ZTS is available...
Zeev
Hey:
It's not we choose ZTS, it is there are many users run with them (IIS,
Apache+workers, and pthreads extension require it)For pthreads I can understand it, but why would users be using it on
IIS/Apache instead of using FastCGI? FastCGI is both faster and more
robust. Is it a matter of lack of knowledge, or is there a real reason to
use it?and all PHP extensions supports it, so if O+ doesn't, it feel a little
inconsistent.My question was outside the context of O+ - it should support it for as long
as ZTS is available...
Oh, in that case, I prefer fcgi(eg: nginx fpm) too. :)
thanks
Zeev
--
Laruence Xinchen Hui
http://www.laruence.com/
hi Zeev,
Which brings me to the subject of this mail – why are you using ZTS PHP
instead of single threaded PHP? The reasons not to use it are few but
fairly major – it’s significantly slower than the non-ZTS PHP, and it’s
significantly less robust in the sense that a single bug somewhere can
bring down an entire server (or at least a bunch of many different
threads). What are your reasons to choose it over FastCGI?
There are situations where FPM/FCGI are not appropriate, or the server
used does not support NTS (Apache windows for example, when fcgi is
not an option).
However, in the long run, I would like to kill TSRM altogether, moving
the file/IO related parts where they should be implemented, either the
engine or main. Does it mean we will kill thread safety by doing so?
No. My idea is to replace it with LTS (thread local storage) which
drastically reduce the thread safety issues due to its exact nature,
store local thread data per thread and not per process. Issues include
well know crashes due to non thread safe code (almost none left in
core, but some libs have issues) and brings a huge performance
improvement.
The other main reason from my side to keep ZTS is Windows. Windows
cannot perform well using process based SAPI. It won't match linux as
long as it runs within a webserver using a process based
implementation (but CLI does not match linux performance and is even
faster in a couple of use cases). I've made some tests to write new
ISAPIs for IIS8 and with the httpkernel (1). The performance are very
promising, given that it is still only a proof of concepts. Having an
ISAPI also allows a tighter integration to IIS8 (pipelines, auths,
scripting, etc.), which is not possible to do now using fastcgi (no
direct access but using RMI or the IIS shell, but horrible, in all
possible ways).
Conclusion:
Yes, TSRM is horrible and does not match modern thread safe
implementation (APC does it better for its usage f.e. using rwlock).
However it would be a very bad idea to give up on thread safety only
because the relatively new trend is all about single threaded/process
based implementation. These systems have limits and I'm sure we will
see some big change in this area in the couple of years. TLS will let
us to do the transition and we can 'easily' support extension
developers to port their extensions.
(1) similar to our builtin webserver except that it can be used in
production servers. It is what IIS used under the hood. Having a SAPI
relying directly on HttpKernel will allow one to create many app pools
using PHP only. It will work smoothly even if IIS runs on the same
host, sharing the same IPs or ports, even the cache will work.
Cheers.
Pierre
@pierrejoye
The other main reason from my side to keep ZTS is Windows. Windows
cannot perform well using process based SAPI. It won't match linux as
long as it runs within a webserver using a process based
implementation (but CLI does not match linux performance and is even
faster in a couple of use cases).
I mean:
but CLI does match linux performance and is even faster in a couple of
use cases :)
--
Pierre
@pierrejoye
The other main reason from my side to keep ZTS is Windows. Windows
cannot
perform well using process based SAPI.
Windows actually works quite well with FastCGI. So well Microsoft even
created their own version for IIS. It's outperforming the ISAPI module by
a wide margin.
Other than Apache/Windows not having FastCGI support(*), I really can't
imagine any situation where using ZTS inside of a Web Server context makes
any sense at all. I wouldn't call it a new trend, it's both old (I've
been pushing for it since at least 2006, probably earlier) and with very
solid technical reasons (faster, more reliable).
Yes, TSRM is horrible and does not match modern thread safe
implementation
(APC does it better for its usage f.e. using rwlock).
Note that I wasn't talking about the implementation of ZTS, but why you
would want to use it in the first place. I actually think that using
thread local storage is much better than using locks - but if you can make
the whole problem disappear because there's no need for thread safety,
that's even better. Why heavily invest in something unless there's a very
good reason to use it?
Zeev
(*) Apache actually does have a good FastCGI implementation available in
Zend Server for Windows (including the free CE version). Using it is
faster and more reliable than using mod_php on Windows.
The other main reason from my side to keep ZTS is Windows. Windows
cannot
perform well using process based SAPI.Windows actually works quite well with FastCGI. So well Microsoft even
created their own version for IIS. It's outperforming the ISAPI module by
a wide margin.
Laziness and design mistake. Everything on windows (AD,IIS, asp.net, etc)
uses thread.
And no, nuts is not faster. I am not talking about PHP zts, but in general.
Other than Apache/Windows not having FastCGI support(*), I really can't
imagine any situation where using ZTS inside of a Web Server context makes
any sense at all. I wouldn't call it a new trend, it's both old (I've
been pushing for it since at least 2006, probably earlier) and with very
solid technical reasons (faster, more reliable).
Miss the rest of my mail or? Current implementation is outdated and slow.
Yes, TSRM is horrible and does not match modern thread safe
implementation
(APC does it better for its usage f.e. using rwlock).Note that I wasn't talking about the implementation of ZTS, but why you
would want to use it in the first place. I actually think that using
thread local storage is much better than using locks - but if you can make
the whole problem disappear because there's no need for thread safety,
that's even better. Why heavily invest in something unless there's a very
good reason to use it?
See what I wrote in my previous reply.
Cheers,
Laziness and design mistake. Everything on windows (AD,IIS, asp.net,
etc)
uses thread.
Well, most other things don't create "shared-nothing" environments like
PHP does. ASP, not only due to the Application object, for instance
isn't shared-nothing like PHP but sharing state. So what we're doing,
basically, is emulate a separation of threads, similar to what an
operating system should do with processes.
Of course an opcode cache isn't shred-nothing either, and maybe sharing
opcodes within a process is faster than doing this in shared memory.
Miss the rest of my mail or? Current implementation is outdated and
slow.
That is true. Many modern compilers and environments provide better
support for thread local storages ....
What I see is that TSRM brings a lot of complexity and introduces risk
of bugs in there as many developers don't think about. Most of us are
focused on the nice and simple world of single-threaded computing. And I
assume that we can still find quite some threading bugs when going on a
hunt for them ... so besides of pure executable performance there is
also the cost of developer power for (proper) maintenance ...
johannes
hi,
On Tue, Jan 29, 2013 at 12:45 PM, Johannes Schlüter
johannes@schlueters.de wrote:
Laziness and design mistake. Everything on windows (AD,IIS, asp.net,
etc)
uses thread.Well, most other things don't create "shared-nothing" environments like
PHP does. ASP, not only due to the Application object, for instance
isn't shared-nothing like PHP but sharing state. So what we're doing,
basically, is emulate a separation of threads, similar to what an
operating system should do with processes.Of course an opcode cache isn't shred-nothing either, and maybe sharing
opcodes within a process is faster than doing this in shared memory.
It is inter process sharing and is very expensive, nothing to compare
with shared memory within a single process, accross many threads.
Miss the rest of my mail or? Current implementation is outdated and
slow.That is true. Many modern compilers and environments provide better
support for thread local storages ....
Exactly, or more exactly CRTs (libc, crt and the likes)>
What I see is that TSRM brings a lot of complexity and introduces risk
of bugs in there as many developers don't think about. Most of us are
focused on the nice and simple world of single-threaded computing. And I
assume that we can still find quite some threading bugs when going on a
hunt for them ... so besides of pure executable performance there is
also the cost of developer power for (proper) maintenance ...
The amount of bugs is rather low. We do test in TS and TS on a daily
basis. The last extension causing more critical issues was mysql, we
have discussed these bugs for a long time.
However let me state my point clear: Giving up on thread safety would
be a mistake as big as safemode and other insane choices we made. That
does mean we have to keep going with the current state but we must
keep it. Other languages support it because most of them are thread
safe by design and allows extensions to rely on that.
Cheers,
Pierre
@pierrejoye
That is true. Many modern compilers and environments provide better
support for thread local storages ....Exactly, or more exactly CRTs (libc, crt and the likes)>
That's what I called "environment" - some of these things depend on
kernels, some on libraries, ... anyway - irrelevant terminology :-p
What I see is that TSRM brings a lot of complexity and introduces risk
of bugs in there as many developers don't think about. Most of us are
focused on the nice and simple world of single-threaded computing. And I
assume that we can still find quite some threading bugs when going on a
hunt for them ... so besides of pure executable performance there is
also the cost of developer power for (proper) maintenance ...The amount of bugs is rather low. We do test in TS and TS on a daily
basis. The last extension causing more critical issues was mysql, we
have discussed these bugs for a long time.
There were mysqli threading bugs, the last one of those actually had
been engine bugs which affected other extensions, too. See i.e.
http://news.php.net/php.internals/59353
Such bugs identified a year after the release of 5.4 gives me quite a
good indication of the little actual testing being done overall.
johannes
On Tue, Jan 29, 2013 at 1:01 PM, Johannes Schlüter
johannes@schlueters.de wrote:
There were mysqli threading bugs, the last one of those actually had
been engine bugs which affected other extensions, too. See i.e.
http://news.php.net/php.internals/59353Such bugs identified a year after the release of 5.4 gives me quite a
good indication of the little actual testing being done overall.
Can you stay fair, check your backlog and the verbose mail exchanges
we had with the mysql connectivity team about these issues? Before and
after the bugs were reported? thanks.
--
Pierre
@pierrejoye
On Tue, Jan 29, 2013 at 1:01 PM, Johannes Schlüter
johannes@schlueters.de wrote:There were mysqli threading bugs, the last one of those actually had
been engine bugs which affected other extensions, too. See i.e.
http://news.php.net/php.internals/59353Such bugs identified a year after the release of 5.4 gives me quite a
good indication of the little actual testing being done overall.Can you stay fair, check your backlog and the verbose mail exchanges
we had with the mysql connectivity team about these issues? Before and
after the bugs were reported? thanks.
I said "There were mysqli threading bugs" and yes, it took some time to
fix those. But to be fair it also has to be mentioned that not all bugs
pushed to "yet another mysqli threading bug" had actually been mysqli
issues.
Out of curiosity I had a quick test: Running wordpress with a bunch of
parallel threads. Immediately found some minor threading issues of this
form:
==19088== Possible data race during read of size 1 at 0x4c82820 by thread #6
==19088== at 0x47747D: pcre_get_compiled_regex_cache (php_pcre.c:387)
==19088== by 0x4777CB: php_pcre_replace (php_pcre.c:986)
==19088== by 0x47794E: php_replace_in_subject (php_pcre.c:1311)
==19088== by 0x478022: preg_replace_impl (php_pcre.c:1409)
==19088== by 0x478377: zif_preg_replace (php_pcre.c:1429)
==19088== by 0x76EC36: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:546)
==19088== by 0x75EA8A: execute_ex (zend_vm_execute.h:356)
==19088== by 0x6E38D2: zend_execute_scripts (zend.c:1316)
==19088== by 0x67C180: php_execute_script (main.c:2479)
==19088== by 0x79E4B1: pconn_do_request (pconnect-sapi.c:208)
==19088== by 0x79E299: php_thread (main.c:63)
==19088== by 0x4A0C01D: mythread_wrapper (hg_intercepts.c:221)
==19088== Address 0x4c82820 is 0 bytes inside a block of size 11 alloc'd
==19088== at 0x4A0626E: malloc (vg_replace_malloc.c:236)
==19088== by 0x339F280871: strdup (in /lib64/libc-2.12.so)
==19088== by 0x339F228FE3: setlocale (in /lib64/libc-2.12.so)
==19088== by 0x449074: seek_to_tz_position (parse_tz.c:283)
==19088== by 0x4490B6: timelib_timezone_id_is_valid (parse_tz.c:312)
==19088== by 0x422231: zif_date_default_timezone_set (php_date.c:4350)
==19088== by 0x76EC36: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:546)
==19088== by 0x75EA8A: execute_ex (zend_vm_execute.h:356)
==19088== by 0x6E38D2: zend_execute_scripts (zend.c:1316)
==19088== by 0x67C180: php_execute_script (main.c:2479)
==19088== by 0x79E4B1: pconn_do_request (pconnect-sapi.c:208)
==19088== by 0x79E299: php_thread (main.c:63)
==19088==
==19088== Possible data race during read of size 1 at 0x4c82820 by thread #3
==19088== at 0x4A07823: strcmp (hg_intercepts.c:2342)
==19088== by 0x4772D7: pcre_get_compiled_regex_cache (php_pcre.c:264)
==19088== by 0x4777CB: php_pcre_replace (php_pcre.c:986)
==19088== by 0x47794E: php_replace_in_subject (php_pcre.c:1311)
==19088== by 0x478022: preg_replace_impl (php_pcre.c:1409)
==19088== by 0x478377: zif_preg_replace (php_pcre.c:1429)
==19088== by 0x76EC36: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:546)
==19088== by 0x75EA8A: execute_ex (zend_vm_execute.h:356)
==19088== by 0x6E38D2: zend_execute_scripts (zend.c:1316)
==19088== by 0x67C180: php_execute_script (main.c:2479)
==19088== by 0x79E4B1: pconn_do_request (pconnect-sapi.c:208)
==19088== by 0x79E299: php_thread (main.c:63)
==19088== Address 0x4c82820 is 0 bytes inside a block of size 11 alloc'd
==19088== at 0x4A0626E: malloc (vg_replace_malloc.c:236)
==19088== by 0x339F280871: strdup (in /lib64/libc-2.12.so)
==19088== by 0x339F228FE3: setlocale (in /lib64/libc-2.12.so)
==19088== by 0x449074: seek_to_tz_position (parse_tz.c:283)
==19088== by 0x4490B6: timelib_timezone_id_is_valid (parse_tz.c:312)
==19088== by 0x422231: zif_date_default_timezone_set (php_date.c:4350)
==19088== by 0x76EC36: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:546)
==19088== by 0x75EA8A: execute_ex (zend_vm_execute.h:356)
==19088== by 0x6E38D2: zend_execute_scripts (zend.c:1316)
==19088== by 0x67C180: php_execute_script (main.c:2479)
==19088== by 0x79E4B1: pconn_do_request (pconnect-sapi.c:208)
==19088== by 0x79E299: php_thread (main.c:63)
So at least on my Linux box there is an issue around the usage of
setlocale(). Gues this won't show on Windows as Windows locale handling
is different, but again a data point showing that most developers don't
spend attention on these things. (and well, handlin locales in a
threaded environment is tough ... as different scripts might use
different locales, similar to the CWD things ....)
johannes
--
Pierre@pierrejoye
On Tue, Jan 29, 2013 at 1:01 PM, Johannes Schlüter
So at least on my Linux box there is an issue around the usage of
setlocale(). Gues this won't show on Windows as Windows locale handling
is different,
but again a data point showing that most developers don't
spend attention on these things. (and well, handlin locales in a
threaded environment is tough ... as different scripts might use
different locales, similar to the CWD things ....)
It is very well known that locale are not TS. Nothing to do with PHP itself.
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Tuesday, January 29, 2013 1:49 PM
To: Johannes Schlüter
Cc: Zeev Suraski; PHP internals
Subject: Re: [PHP-DEV] ZTS - why are you using it?On Tue, Jan 29, 2013 at 12:45 PM, Johannes Schlüter
johannes@schlueters.de wrote:Of course an opcode cache isn't shred-nothing either, and maybe
sharing opcodes within a process is faster than doing this in shared
memory.It is inter process sharing and is very expensive, nothing to compare
with shared
memory within a single process, accross many threads.
What are you basing that assertion on? Shared memory should have
identical performance to regular process memory. It's mapped in very
similar way.
There are effectively no performance advantages to using multiple threads
over multiple processes, none whatsoever. It might help you a bit with
memory consumption - but in the case of PHP, FastCGI with it's n:m mapping
is much superior to it.
Using multiple threads only makes sense if you take functional advantage
of that, like shared objects and such - which we don't.
Miss the rest of my mail or? Current implementation is outdated and
slow.That is true. Many modern compilers and environments provide better
support for thread local storages ....Exactly, or more exactly CRTs (libc, crt and the likes)>
Can we stop arguing about the implementation - which I didn't even bring
up in my original mail - and focus on the original question - why would
you want thread safe PHP in the first place?
So far the only real use case that was brought up was for using pthreads
in a long-running app. I've yet to hear about a single real reason of why
someone would want to use it in web server context that is not based on
misconceptions or myths.
However let me state my point clear: Giving up on thread safety would
be a
mistake as big as safemode and other insane choices we made.
As big as giving up on safe mode or creating it in the first place? If
it's the former, I say let's do it right now :)
Zeev
It is inter process sharing and is very expensive, nothing to compare
with shared
memory within a single process, accross many threads.What are you basing that assertion on? Shared memory should have
identical performance to regular process memory. It's mapped in very
similar way.There are effectively no performance advantages to using multiple threads
over multiple processes, none whatsoever. It might help you a bit with
memory consumption - but in the case of PHP, FastCGI with it's n:m mapping
is much superior to it.Using multiple threads only makes sense if you take functional advantage
of that, like shared objects and such - which we don't.
Testing maybe?
Miss the rest of my mail or? Current implementation is outdated and
slow.That is true. Many modern compilers and environments provide better
support for thread local storages ....Exactly, or more exactly CRTs (libc, crt and the likes)>
Can we stop arguing about the implementation
No, we can't. The main reason of the bugs and performance issue is due
to the current implementation and how extensions developers have to
deal with it. It is not separable from discussing what could be the
worst decision we ever made, droping thread safety.
- which I didn't even bring
up in my original mail - and focus on the original question - why would
you want thread safe PHP in the first place?
I mentioned one which is alone a good enough reason. LTS brings zts in
line with NTS in term of performance while reducing massively the
shared/locks access related bugs for many areas.
So far the only real use case that was brought up was for using pthreads
in a long-running app. I've yet to hear about a single real reason of why
someone would want to use it in web server context that is not based on
misconceptions or myths.
Thanks, it is really nice to say something and being told that what
has been done is misconceptions or myths, especially if you gave up on
thread safety years ago within your company. That's all good, as long
as it only affects your company products and not PHP as a whole.
However let me state my point clear: Giving up on thread safety would
be a
mistake as big as safemode and other insane choices we made.As big as giving up on safe mode or creating it in the first place? If
it's the former, I say let's do it right now :)
both :) But with a small difference, back then TSRM was not bad. But
it was never updated to what is available now on any modern OS.
Cheers,
Pierre
@pierrejoye
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Tuesday, January 29, 2013 2:19 PM
To: Zeev Suraski
Cc: Johannes Schlüter; PHP internals
Subject: Re: [PHP-DEV] ZTS - why are you using it?It is inter process sharing and is very expensive, nothing to compare
with shared
memory within a single process, accross many threads.What are you basing that assertion on? Shared memory should have
identical performance to regular process memory. It's mapped in very
similar way.Testing maybe?
Retest then, you've got it wrong. Shared memory (or memory mapped files
as they'd be on Windows) are simply memory, it's available to the process
in exactly the same way and while the OS does slightly different
book-keeping for it in how it populates the pages - it's negligible.
Miss the rest of my mail or? Current implementation is outdated
and slow.That is true. Many modern compilers and environments provide
better support for thread local storages ....Exactly, or more exactly CRTs (libc, crt and the likes)>
Can we stop arguing about the implementation
No, we can't. The main reason of the bugs and performance issue is due
to the
current implementation and how extensions developers have to deal with
it. It is
not separable from discussing what could be the worst decision we ever
made,
droping thread safety.
Well, I'm not interested in discussing the implementation when the need
isn't clear to me.
For example, you could say that thread-safe PHP would be 2x faster. Or 2x
more memory efficient. Or will enable us to do XYZ which we otherwise
can't.
For now, an utopian ZTS mode would, at best, not give us anything.
Even if we put aside the performance/reliability issues - why would
someone want that mode over other modes?
So far the only real use case that was brought up was for using
pthreads in a long-running app. I've yet to hear about a single real
reason of why someone would want to use it in web server context that
is not based on misconceptions or myths.Thanks, it is really nice to say something and being told that what has
been done
is misconceptions or myths, especially if you gave up on thread safety
years ago
within your company. That's all good, as long as it only affects your
company
products and not PHP as a whole.
Pierre, I'm sorry, but when you state something like '[shared memory] is
inter process sharing and is very expensive', there's no other way to
describe it other than a myth. Better theoretical performance is a
misconception. The best PHP performance/density available today is on
nginx, which couldn't be farther away from
multithreaded-PHP-in-process-arch.
Even after what you just said, you've yet to bring up a single reason for
why one would want to use ZTS inside a web server context. You seem to
love ZTS with a vengeance but you can't quite explain why. My 'company'
didn't decide anything regarding ZTS. It was me, probably the person with
the most experience with ZTS back in the day, and it was probably much
more difficult for me than anybody else to realize that the ZTS approach
was the wrong path to go to as it was my baby project.
BTW, for the love of [insert here], I'm not talking about killing thread
safety. It's useful for long running processes, and who knows, maybe in
the future we'll have threads inside PHP. But I am talking about
telling people that using ZTS in production is not recommended and that
they should be using FastCGI instead.
Zeev
As a developer I really enjoyed that discussion, it was very
informative for me. I'm always stuck with question which version of
PHP to use.
2013/1/29 Zeev Suraski zeev@zend.com:
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Tuesday, January 29, 2013 2:19 PM
To: Zeev Suraski
Cc: Johannes Schlüter; PHP internals
Subject: Re: [PHP-DEV] ZTS - why are you using it?It is inter process sharing and is very expensive, nothing to compare
with shared
memory within a single process, accross many threads.What are you basing that assertion on? Shared memory should have
identical performance to regular process memory. It's mapped in very
similar way.Testing maybe?
Retest then, you've got it wrong. Shared memory (or memory mapped files
as they'd be on Windows) are simply memory, it's available to the process
in exactly the same way and while the OS does slightly different
book-keeping for it in how it populates the pages - it's negligible.Miss the rest of my mail or? Current implementation is outdated
and slow.That is true. Many modern compilers and environments provide
better support for thread local storages ....Exactly, or more exactly CRTs (libc, crt and the likes)>
Can we stop arguing about the implementation
No, we can't. The main reason of the bugs and performance issue is due
to the
current implementation and how extensions developers have to deal with
it. It is
not separable from discussing what could be the worst decision we ever
made,
droping thread safety.Well, I'm not interested in discussing the implementation when the need
isn't clear to me.
For example, you could say that thread-safe PHP would be 2x faster. Or 2x
more memory efficient. Or will enable us to do XYZ which we otherwise
can't.
For now, an utopian ZTS mode would, at best, not give us anything.
Even if we put aside the performance/reliability issues - why would
someone want that mode over other modes?So far the only real use case that was brought up was for using
pthreads in a long-running app. I've yet to hear about a single real
reason of why someone would want to use it in web server context that
is not based on misconceptions or myths.Thanks, it is really nice to say something and being told that what has
been done
is misconceptions or myths, especially if you gave up on thread safety
years ago
within your company. That's all good, as long as it only affects your
company
products and not PHP as a whole.Pierre, I'm sorry, but when you state something like '[shared memory] is
inter process sharing and is very expensive', there's no other way to
describe it other than a myth. Better theoretical performance is a
misconception. The best PHP performance/density available today is on
nginx, which couldn't be farther away from
multithreaded-PHP-in-process-arch.Even after what you just said, you've yet to bring up a single reason for
why one would want to use ZTS inside a web server context. You seem to
love ZTS with a vengeance but you can't quite explain why. My 'company'
didn't decide anything regarding ZTS. It was me, probably the person with
the most experience with ZTS back in the day, and it was probably much
more difficult for me than anybody else to realize that the ZTS approach
was the wrong path to go to as it was my baby project.BTW, for the love of [insert here], I'm not talking about killing thread
safety. It's useful for long running processes, and who knows, maybe in
the future we'll have threads inside PHP. But I am talking about
telling people that using ZTS in production is not recommended and that
they should be using FastCGI instead.Zeev
--
--
Pozdrawiam,
Damian Tylczyński
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Tuesday, January 29, 2013 2:19 PM
To: Zeev Suraski
Cc: Johannes Schlüter; PHP internals
Subject: Re: [PHP-DEV] ZTS - why are you using it?It is inter process sharing and is very expensive, nothing to compare
with shared
memory within a single process, accross many threads.What are you basing that assertion on? Shared memory should have
identical performance to regular process memory. It's mapped in very
similar way.Testing maybe?
Retest then, you've got it wrong. Shared memory (or memory mapped files
as they'd be on Windows) are simply memory, it's available to the process
in exactly the same way and while the OS does slightly different
book-keeping for it in how it populates the pages - it's negligible.
It is not negligible, also the locking is different. Also, if I
remember correctly there is no rwlock support either, which is a huge
cons.
No, we can't. The main reason of the bugs and performance issue is due
to the
current implementation and how extensions developers have to deal with
it. It is
not separable from discussing what could be the worst decision we ever
made,
droping thread safety.Well, I'm not interested in discussing the implementation when the need
isn't clear to me.
For example, you could say that thread-safe PHP would be 2x faster. Or 2x
more memory efficient. Or will enable us to do XYZ which we otherwise
can't.
There are quite a few things I can do on Windows only in thread safe
environments (f.e. ESENT, builtin DB, used by AD for example, damned
fast).
For now, an utopian ZTS mode would, at best, not give us anything.
Even if we put aside the performance/reliability issues - why would
someone want that mode over other modes?
I must be really unclear or something along this line. Alone on IIS,
there are dozen of features you can't do nor use using fastcgi. Apache
could also be used in a better way (windows here too, linux has a
module for both builds of apache).
btw, have you tried to compare IIS/FastCGI (I won't even try with
apache+fastcgi) on Windows vs nginx-fpm on linux? I would be very
surprised if your numbers show that they are equivalent.
Pierre, I'm sorry, but when you state something like '[shared memory] is
inter process sharing and is very expensive', there's no other way to
describe it other than a myth. Better theoretical performance is a
misconception. The best PHP performance/density available today is on
nginx, which couldn't be farther away from
multithreaded-PHP-in-process-arch.Even after what you just said, you've yet to bring up a single reason for
why one would want to use ZTS inside a web server context. You seem to
love ZTS with a vengeance but you can't quite explain why. My 'company'
didn't decide anything regarding ZTS. It was me, probably the person with
the most experience with ZTS back in the day, and it was probably much
more difficult for me than anybody else to realize that the ZTS approach
was the wrong path to go to as it was my baby project.
It could have been the wrong path for some situation back then, but it
is definitively not wrong to improve thread safety.
I would rather have one single build instead, and enable the ts
related stuff when necessary. It will add some more functions in the
engine but it would be much more clear and easier than what we have
now.
BTW, for the love of [insert here], I'm not talking about killing thread
safety.
That's how it looks and that's where this discussion is going, tbh.
It's useful for long running processes, and who knows, maybe in
the future we'll have threads inside PHP. But I am talking about
telling people that using ZTS in production is not recommended and that
they should be using FastCGI instead.
As far as I remember, we already do that for a couple of web servers.
And in the long run, I will rather tell not to use FastCGI for
dedicated hosting and the likes. That being said, I also met many ISPs
which are not happy with the all-fastcgi, memory usageand performance
were the issues (have to read my backlog for other details :).
Cheers,
Pierre
@pierrejoye
As far as I remember, we already do that for a couple of web servers.
And in the long run, I will rather tell not to use FastCGI for
dedicated hosting and the likes. That being said, I also met many ISPs
which are not happy with the all-fastcgi, memory usageand performance
were the issues (have to read my backlog for other details :).
Those ISPs are probably stuck in old fastcgi-land and haven't figured
out FPM's ondemand pooling. If you idle out the ondemand children
somewhat quickly you can support a lot of vhosts without using much
memory since each one doesn't need to have a running process. Only hosts
actually being accessed will have running processes.
-Rasmus
Those ISPs are probably stuck in old fastcgi-land and haven't figured
out FPM's ondemand pooling. If you idle out the ondemand children
somewhat quickly you can support a lot of vhosts without using much
memory since each one doesn't need to have a running process. Only hosts
actually being accessed will have running processes.
Not talking about Linux here, but IIS have something similar, but
really not even close to how FPM performs or how it works (having
basically the pros of TS and NTS).
Cheers,
Pierre
@pierrejoye
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Tuesday, January 29, 2013 3:37 PM
To: Rasmus Lerdorf
Cc: PHP internals
Subject: Re: [PHP-DEV] ZTS - why are you using it?On Tue, Jan 29, 2013 at 2:33 PM, Rasmus Lerdorf rasmus@lerdorf.com
wrote:Those ISPs are probably stuck in old fastcgi-land and haven't figured
out FPM's ondemand pooling. If you idle out the ondemand children
somewhat quickly you can support a lot of vhosts without using much
memory since each one doesn't need to have a running process. Only
hosts actually being accessed will have running processes.Not talking about Linux here, but IIS have something similar, but really
not even
close to how FPM performs or how it works (having basically the pros of
TS and
NTS).
On Windows with impersonation you're actually in a better situation than
you are in Linux. You could hold a small pool of processes and handle as
many different users as you'd like.
Zeev
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Tuesday, January 29, 2013 3:37 PM
To: Rasmus Lerdorf
Cc: PHP internals
Subject: Re: [PHP-DEV] ZTS - why are you using it?On Tue, Jan 29, 2013 at 2:33 PM, Rasmus Lerdorf rasmus@lerdorf.com
wrote:Those ISPs are probably stuck in old fastcgi-land and haven't figured
out FPM's ondemand pooling. If you idle out the ondemand children
somewhat quickly you can support a lot of vhosts without using much
memory since each one doesn't need to have a running process. Only
hosts actually being accessed will have running processes.Not talking about Linux here, but IIS have something similar, but really
not even
close to how FPM performs or how it works (having basically the pros of
TS and
NTS).On Windows with impersonation you're actually in a better situation than
you are in Linux. You could hold a small pool of processes and handle as
many different users as you'd like.
Works fine with ZTS too btw, IIS takes care about managing the
respective application pools.
But yes, impersonation is a huge on Windows/IIS, get ride of
openbasedir and all that in one go (and again, not NTS specific).
Cheers,
Pierre
@pierrejoye
On Windows with impersonation you're actually in a better situation than
you are in Linux. You could hold a small pool of processes and handle as
many different users as you'd like.
Works fine with ZTS too btw, IIS takes care about managing the
respective application pools.But yes, impersonation is a huge on Windows/IIS, get ride of
openbasedir and all that in one go (and again, not NTS specific).
Wouldn't that be equivalent security-wise to running the server on linux
as root for
calling setuid() to each user?
On Windows with impersonation you're actually in a better situation than
you are in Linux. You could hold a small pool of processes and handle as
many different users as you'd like.
Works fine with ZTS too btw, IIS takes care about managing the
respective application pools.But yes, impersonation is a huge on Windows/IIS, get ride of
openbasedir and all that in one go (and again, not NTS specific).Wouldn't that be equivalent security-wise to running the server on linux
as root for
calling setuid() to each user?
No, not the same, while the results look the same.
Cheers,
Pierre
@pierrejoye
On Windows with impersonation you're actually in a better situation than
you are in Linux. You could hold a small pool of processes and handle as
many different users as you'd like.
Works fine with ZTS too btw, IIS takes care about managing the
respective application pools.But yes, impersonation is a huge on Windows/IIS, get ride of
openbasedir and all that in one go (and again, not NTS specific).Wouldn't that be equivalent security-wise to running the server on linux
as root for
calling setuid() to each user?
No, because the process is reusable and can be switched to other creds.
Zeev
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Tuesday, January 29, 2013 3:19 PM
To: Zeev Suraski
Cc: Johannes Schlüter; PHP internals
Subject: Re: [PHP-DEV] ZTS - why are you using it?-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Tuesday, January 29, 2013 2:19 PM
To: Zeev Suraski
Cc: Johannes Schlüter; PHP internals
Subject: Re: [PHP-DEV] ZTS - why are you using it?It is inter process sharing and is very expensive, nothing to
compare
with shared
memory within a single process, accross many threads.What are you basing that assertion on? Shared memory should have
identical performance to regular process memory. It's mapped in
very similar way.Testing maybe?
Retest then, you've got it wrong. Shared memory (or memory mapped
files as they'd be on Windows) are simply memory, it's available to
the process in exactly the same way and while the OS does slightly
different book-keeping for it in how it populates the pages - it's
negligible.It is not negligible, also the locking is different. Also, if I remember
correctly
there is no rwlock support either, which is a huge cons.
It is too negligible. Once the pages get allocated and mapped properly -
it's exactly the same thing as accessing memory.
Locking in between processes is indeed slower than locking inside
processes, but at the risk of sounding like a broken record, in something
like an opcode cache (few writes, mostly reads), it's negligible.
For example, you could say that thread-safe PHP would be 2x faster.
Or 2x more memory efficient. Or will enable us to do XYZ which we
otherwise can't.There are quite a few things I can do on Windows only in thread safe
environments (f.e. ESENT, builtin DB, used by AD for example, damned
fast).
OK, now we're getting somewhere. So ESENT is one legit use case that
would benefit from a multithreaded PHP.
For now, an utopian ZTS mode would, at best, not give us anything.
Even if we put aside the performance/reliability issues - why would
someone want that mode over other modes?I must be really unclear or something along this line. Alone on IIS,
there are
dozen of features you can't do nor use using fastcgi. Apache could also
be used
in a better way (windows here too, linux has a module for both builds of
apache).
Which ones?
btw, have you tried to compare IIS/FastCGI (I won't even try with
apache+fastcgi) on Windows vs nginx-fpm on linux? I would be very
surprised if your numbers show that they are equivalent.
Not recently. But I'd be surprised if it wasn't equivalent at least as
far PHP is concerned. Nginx is marginally faster in pure PHP performance
than Apache; Where it really shines is that it can do it with fewer
processes -> much less memory consumption. That attribute stems from
breaking the 1:1 mapping and turning it into an n:m mapping.
It could have been the wrong path for some situation back then, but it
is
definitively not wrong to improve thread safety.
I didn't suggest that. My original question was 'Why do you use
thread-safe ZTS'. It was explicitly not an RFC to stop developing or
remove ZTS mode.
I do think that we'll do our users a much better service if we tell them
that unless they have a very good reason to use a web server plugin on a
multithreaded server, they should use FastCGI instead.
BTW, for the love of [insert here], I'm not talking about killing
thread safety.That's how it looks and that's where this discussion is going, tbh.
Well, it wasn't my intention, at all. I was genuinely surprised there was
a high level of interest about ZTS when we discussed Optimizer+, which
made me wonder why that is the case.
It's useful for long running processes, and who knows, maybe in the
future we'll have threads inside PHP. But I am talking about
telling people that using ZTS in production is not recommended and
that they should be using FastCGI instead.As far as I remember, we already do that for a couple of web servers.
And in the long run, I will rather tell not to use FastCGI for dedicated
hosting and
the likes. That being said, I also met many ISPs which are not happy
with the all-
fastcgi, memory usageand performance were the issues (have to read my
backlog for other details :).
I think that properly configured FastCGI will be superior to a
server-plugin in mostly every way. The one downside is that you lose the
server-specific features, but that's typically not a huge price to pay.
Zeev
As far as I remember, we already do that for a couple of web servers.
And in the long run, I will rather tell not to use FastCGI for
dedicated hosting and the likes. That being said, I also met many ISPs
which are not happy with the all-fastcgi, memory usageand performance
were the issues (have to read my backlog for other details :).
I myself wouldn't use current-PHP for shared hosting in ZTS mode. Stack
overflows (functrion nesting, pcre, ...) will kill the whole process so
one bad guy can hurt other parallel requests for other vhosts quite
easily. With a multi-process-setup such bad user can hurt performance
but not completely kill other requests.
That aside: I agree that a system written for threaded environments can
benefit from threads vs. processes (not only memory access, but also
context switches etc.) at least on some operating systems. But PHP
(currently) is not that kind of a system. (I went through this quite a
bit with Solaris devs in the past, which led to some improvements which
were available via http://hg.genunix.org/php-experiment.hg/ which seems
to be down ...)
My primary perspective is that I claim that barely anybody is doing more
than compile-testing in ZTS mode. TSRM macros are also often one of the
biggest causes of confusion when teaching extension writing/patching of
PHP, even though for 95% of the cases it can be seen as a pure blackbox.
I for one would vote for a simplification of the codebase over a small
performance win.
johannes
Hi!
Of course an opcode cache isn't shred-nothing either, and maybe sharing
opcodes within a process is faster than doing this in shared memory.
I don't think so. IIRC main time is spent of two things: building
runtime structures from storage formats (because we mess with our
structures in runtime, we can not run engine on shm copies of
everything) and ensuring writing new scripts does not mess with existing
ones. These will have to be done regardless of how shared storage is
organized.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
(*) Apache actually does have a good FastCGI implementation available in
Zend Server for Windows (including the free CE version). Using it is
faster and more reliable than using mod_php on Windows.
Absolute right. Zend Server works great on Windows with FastCGI.
Using it since 3 years and got never problems.
Hi!
There are situations where FPM/FCGI are not appropriate, or the server
used does not support NTS (Apache windows for example, when fcgi is
not an option).
Why Apache can't use FCGI? There's no proper driver os something in
Apache architecture prevents it from using FCGI?
No. My idea is to replace it with LTS (thread local storage) which
drastically reduce the thread safety issues due to its exact nature,
I'm not sure it will. Our threading issues mainly related to libraries
using global context and either not protecting it at all (e.g. ICU uses
- or at least did couple of years ago - some global variables as caches
which are locale-dependent, and once these cache vars are set, it's
almost impossible to change and it leads to context leaking between
threads) or protecting it improperly so that we get race conditions or
crashes. Moving our data to LTS would make our part faster but won't
make these libraries work better.
The other main reason from my side to keep ZTS is Windows. Windows
cannot perform well using process based SAPI. It won't match linux as
I don't see why. With proper prefork model, cost of process creation
does not matter too much, and I've seen decent performance results with
FCGI. Actually, IIRC, performance hit from ZTS is more than performance
hit from multiprocess model. There are other things that make windows
performance lag (Unicode APIs and filesystem being one of the factors,
for example) but I do not think process model is a major factor here.
promising, given that it is still only a proof of concepts. Having an
ISAPI also allows a tighter integration to IIS8 (pipelines, auths,
scripting, etc.), which is not possible to do now using fastcgi (no
direct access but using RMI or the IIS shell, but horrible, in all
possible ways).
This is true, however I am not convinced it should be in PHP as opposed
to separate user modules... If you'd want to run PHP code in IIS
pipeline, I imagine performance-wise it would be expensive - setting up
PHP request is not a cheap thing, compared to what auth stage usually does.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
There are situations where FPM/FCGI are not appropriate, or the server
used does not support NTS (Apache windows for example, when fcgi is
not an option).Why Apache can't use FCGI? There's no proper driver os something in
Apache architecture prevents it from using FCGI?
No, more by choice (out of the developer control).
No. My idea is to replace it with LTS (thread local storage) which
drastically reduce the thread safety issues due to its exact nature,I'm not sure it will. Our threading issues mainly related to libraries
using global context and either not protecting it at all (e.g. ICU uses
- or at least did couple of years ago - some global variables as caches
which are locale-dependent, and once these cache vars are set, it's
almost impossible to change and it leads to context leaking between
threads) or protecting it improperly so that we get race conditions or
crashes. Moving our data to LTS would make our part faster but won't
make these libraries work better.
I did not check latest ICU code base but we never had any issues in
intl in ZTS. However you are right, since 5.3.0 most TS issues were in
libs, on windows I fixed a couple by patching the libraries when
possible (the oss ones).
The other main reason from my side to keep ZTS is Windows. Windows
cannot perform well using process based SAPI. It won't match linux asI don't see why. With proper prefork model, cost of process creation
does not matter too much, and I've seen decent performance results with
FCGI.
I never said fcgi performs badly. What I say is that Windows design is
not process based, none of the hiperformence tools available on this
platform is based on threads (AD, IIS, asp.net, etc.).
Actually, IIRC, performance hit from ZTS is more than performance
hit from multiprocess model. There are other things that make windows
performance lag (Unicode APIs and filesystem being one of the factors,
for example) but I do not think process model is a major factor here.
Filesystem is getting better, it is already better in 5.3.0+ and will
be a bit better in 5.5.0 (if I got the time to do it :/). We do not
use the unicode API yet (for IO or FS), so no real impact yet but a
few functions that still have to use it in some libs or in core.
promising, given that it is still only a proof of concepts. Having an
ISAPI also allows a tighter integration to IIS8 (pipelines, auths,
scripting, etc.), which is not possible to do now using fastcgi (no
direct access but using RMI or the IIS shell, but horrible, in all
possible ways).This is true, however I am not convinced it should be in PHP as opposed
to separate user modules... If you'd want to run PHP code in IIS
pipeline, I imagine performance-wise it would be expensive
To bring zts in line with NTS in term of performance is possible, look
at Arnaud's 1st draft for a TLS support in php:
- setting up
PHP request is not a cheap thing, compared to what auth stage usually does.
The IIS pipeline architecture allows much more than only auth, much more.
Let me repeat it a last time, I do think that giving up on ZTS
altogether is a very bad idea, to say it in a nice way. That's the
kind of choice that will shoot at us back very soon. I agree that it
adds some work, but 99% of us do not care but there are solutions to
ease the developer work and reduce the wtf factors. TLS is one of
them.
Cheers,
Pierre
@pierrejoye
Hi!
I did not check latest ICU code base but we never had any issues in
intl in ZTS. However you are right, since 5.3.0 most TS issues were in
One of them has to do with number formatting, so if you have a number of
apps that use different locale settings on the same server, which have
different number separators, you may encounter it. Not a frequent use
case, though. See: http://bugs.icu-project.org/trac/ticket/6711
Not unique to TS, but there might be ones that are, if they use globals
in this manner. Just showing that modern libraries are still having this
kind of issues, and it's very hard to get maintainers to fix them.
I never said fcgi performs badly. What I say is that Windows design is
not process based, none of the hiperformence tools available on this
platform is based on threads (AD, IIS, asp.net, etc.).
ITYM based or processes, or s/none/all/. But so what? For IIS case
threads are fine, but for our case - shared-nothing - they don't help us
much. No idea what asp.net does but they probably designed it to be
threaded from scratch, so it probably has very different architecture
than PHP.
Filesystem is getting better, it is already better in 5.3.0+ and will
be a bit better in 5.5.0 (if I got the time to do it :/). We do not
use the unicode API yet (for IO or FS), so no real impact yet but a
few functions that still have to use it in some libs or in core.
AFAIR all APIs that go into filesystem, C library, etc. ultimately end
up with Unicode - i.e.
To bring zts in line with NTS in term of performance is possible, look
at Arnaud's 1st draft for a TLS support in php:
TLS is nice, I have nothing against TLS, and if somebody wants to get
behind the effort to get ZTS to use TLS, great. But I was talking about
cost of setting up envt for PHP script, which is not going to change.
You need to initialize all the globals, create all the structures, etc.
etc. - it's all not free.
The IIS pipeline architecture allows much more than only auth, much more.
I know, it's just an example. I'm just saying PHP request init is
expensive, and I'm not even sure we can do proper init on early stages
of IIS request... So PHP may not be the best thing to use inside IIS
pipeline in general case.
ease the developer work and reduce the wtf factors. TLS is one of
them.
Fine, so who's going to do this? This RFC is marked with 2008, now it's
2013 and it didn't happen. Why?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
hi,
Hi!
I did not check latest ICU code base but we never had any issues in
intl in ZTS. However you are right, since 5.3.0 most TS issues were inOne of them has to do with number formatting, so if you have a number of
apps that use different locale settings on the same server, which have
different number separators, you may encounter it. Not a frequent use
case, though. See: http://bugs.icu-project.org/trac/ticket/6711
" I can confirm the ICU version 3.8 worked well"
Every maintained software (with active users ;) has bugs, which get fixed.
Not unique to TS, but there might be ones that are, if they use globals
in this manner. Just showing that modern libraries are still having this
kind of issues, and it's very hard to get maintainers to fix them.
Yes, but they are very open to get these issues fixed.
I never said fcgi performs badly. What I say is that Windows design is
not process based, none of the hiperformence tools available on this
platform is based on threads (AD, IIS, asp.net, etc.).ITYM based or processes, or s/none/all/. But so what? For IIS case
threads are fine, but for our case - shared-nothing - they don't help us
much. No idea what asp.net does but they probably designed it to be
threaded from scratch, so it probably has very different architecture
than PHP.
We do only do share nothing for the engine (related to script
execution). There are other parts where we do share (realpath for one,
pcre, etc.). Also I think that's something we should investigate
instead of taking (yet again) the easiest or trendy way.
Filesystem is getting better, it is already better in 5.3.0+ and will
be a bit better in 5.5.0 (if I got the time to do it :/). We do not
use the unicode API yet (for IO or FS), so no real impact yet but a
few functions that still have to use it in some libs or in core.AFAIR all APIs that go into filesystem, C library, etc. ultimately end
up with Unicode - i.e.
It is not unicode per se and there is not necessary a conversion
happening, at least with NTFS filesystems. But that's another topic :)
To bring zts in line with NTS in term of performance is possible, look
at Arnaud's 1st draft for a TLS support in php:TLS is nice, I have nothing against TLS, and if somebody wants to get
behind the effort to get ZTS to use TLS, great. But I was talking about
cost of setting up envt for PHP script, which is not going to change.
You need to initialize all the globals, create all the structures, etc.
etc. - it's all not free.
But you ignore that TLS brings ZTS in line with NTS from a performance
point of view. And it is only one of the possible gain.
The IIS pipeline architecture allows much more than only auth, much more.
I know, it's just an example. I'm just saying PHP request init is
expensive, and I'm not even sure we can do proper init on early stages
of IIS request... So PHP may not be the best thing to use inside IIS
pipeline in general case.
I'd to disagree. And giving up only because it may require some more
work sounds really bad to me.
ease the developer work and reduce the wtf factors. TLS is one of
them.Fine, so who's going to do this? This RFC is marked with 2008, now it's
2013 and it didn't happen. Why?
Nice to totally ignore the results you were asking for... And as of
why, these changes could not be done in 5.x. We discussed the idea
with the engine guys back then, and even last year again.
Anyway, I have given enough arguments and this discussion is being in
a loop now.
Cheers,
Pierre
@pierrejoye
I didn’t want to hijack the Optimizer+ thread so I’m creating a new one,
based on the apparent level of interest in ZTS. This isn’t an RFC to
remove ZTS by any stretch, but I am a bit confused about why people are
still using ZTS.
I doubt many people use it in production, especially under "high" load.
About a year ago I've spent quite some time fixing threading issues in
different parts of PHP (object instantiation in the engine, mysqli, ...)
there were a few bug reports but considering how simple it was to
exploit some of the bugs (<?php new stdclass; ?>, or any other internal
class, was all that was needed for one of the bugs) there were way too
few reports.
johannes
exploit some of the bugs (<?php new stdclass; ?>, or any other internal
class, was all that was needed for one of the bugs) there were way too
few reports.
Ah, that specific bug was 5.4-only, back then 5.4 was quite new. But
there were other bugs, too.
johannes
Which brings me to the subject of this mail – why are you using ZTS
PHP instead of single threaded PHP? The reasons not to use it are few
but fairly major – it’s significantly slower than the non-ZTS PHP, and
it’s significantly less robust in the sense that a single bug
somewhere can bring down an entire server (or at least a bunch of many
different threads). What are your reasons to choose it over FastCGI?
I have no reasons to ever use it. I've thought about dropping the
support of ZTS in Xdebug for a while now. I might just do that when 5.5
comes along...
cheers,
Derick
I’m creating a new one,
based on the apparent level of interest in ZTS. This isn’t an RFC to
remove ZTS by any stretch, but I am a bit confused about why people are
still using ZTS.
Personally because runkit sandbox requires it, amongst other extensions.
Haven't had a chance to play with it yet but the new pthreads extension
requires it which I'm probably going to be using extensively in future too.
Why does it need to be enabled for most people? It probably doesn't, but
there are many third part extensions that can't function without it with
no obvious workarounds that would cease to exist if it hypothetically
disappeared. This for me, and I suppose many others would be a fairly
major problem.