On Wed, Jan 30, 2013 at 1:42 PM, Zeev Suraski wrote:
> In case I wasn't sufficiently clear, I'm talking about putting PHP inside
> a *multithreaded web server*, not being a good idea.
It makes no sense where FPM is supported, or little sense.
> The use case you
> specify is exactly the use case
Op 30 jan. 2013, om 13:42 heeft Zeev Suraski het volgende geschreven:
>> -Original Message-
>> From: Bas van Beek [mailto:b...@tobin.nl]
>> Sent: Wednesday, January 30, 2013 2:29 PM
>> To: Zeev Suraski
>> Cc: Pierre Joye; Stas Malyshev; PHP internals
>&
> -Original Message-
> From: Bas van Beek [mailto:b...@tobin.nl]
> Sent: Wednesday, January 30, 2013 2:29 PM
> To: Zeev Suraski
> Cc: Pierre Joye; Stas Malyshev; PHP internals
> Subject: Re: [PHP-DEV] ZTS - why are you using it?
>
> Hi Guys,
>
> As a heavy use
Hi Guys,
As a heavy user of ZTS in multi threaded C/C++ applications, here are my $0.02.
Removing ZTS would be a bad idea for all those custom multi-threaded
applications out there that allow some form of internal/embedded PHP scripting.
These applications are not web-servers but do make use of
On 29/01/2013 09:03, Zeev Suraski wrote:
> 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 e
> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Wednesday, January 30, 2013 8:10 AM
> To: Stas Malyshev
> Cc: Zeev Suraski; PHP internals
> Subject: Re: [PHP-DEV] ZTS - why are you using it?
>
> On Wed, Jan 30, 2013 at 2:15 AM, Stas M
On Wed, Jan 30, 2013 at 11:33 AM, Lester Caine wrote:
> Stas Malyshev wrote:
>>>
>>> The TS model in php should be redesigned in the next major version,
>>> >instead of simply giving it up.
>>
>> Again, I'd not mind seeing this redesign, but do we have somebody who's
>> actually going to do that?
Stas Malyshev wrote:
The TS model in php should be redesigned in the next major version,
>instead of simply giving it up.
Again, I'd not mind seeing this redesign, but do we have somebody who's
actually going to do that?
Ignoring the problem of 'someone to do it', in this age of multi-core sys
hi,
On Wed, Jan 30, 2013 at 7:42 AM, Stas Malyshev wrote:
> 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 th
Hi!
> Right, but they do not give up thread safety. See "Thread State and
> the Global Interpreter Lock" in:
>
> http://docs.python.org/2/c-api/init.html
That's whole different concept of thread safety. It's basically saying
"you can do anything you want outside of Python engine but only one
thr
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
differ
On 01/30/2013 07:09 AM, Pierre Joye wrote:
> On Wed, Jan 30, 2013 at 2:15 AM, Stas Malyshev
wrote:
>> Hi!
>>
>>> Python, for example, is thread safe by default. Extensions developers
>>
>> Doesn't Python have global engine lock?
>
> Right, but they do not give up thread safety. See "Thread State a
On Wed, Jan 30, 2013 at 2:15 AM, Stas Malyshev wrote:
> Hi!
>
>> Python, for example, is thread safe by default. Extensions developers
>
> Doesn't Python have global engine lock?
Right, but they do not give up thread safety. See "Thread State and
the Global Interpreter Lock" in:
http://docs.pyth
On Wed, Jan 30, 2013 at 12:49 AM, Stas Malyshev wrote:
> 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
Hi!
> Python, for example, is thread safe by default. Extensions developers
Doesn't Python have global engine lock?
> It was and still is a lazy and design mistake to have focused on
> FastCGI to support PHP on IIS more easily, while everything else in
> this stack uses what the whole OS stack d
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 r
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
On Jan 29, 2013 9:42 PM, "Johannes Schlüter" wrote:
>
> On Tue, 2013-01-29 at 13:13 +0100, Pierre Joye wrote:
> > 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 loca
On Tue, 2013-01-29 at 13:13 +0100, Pierre Joye wrote:
> On Tue, Jan 29, 2013 at 1:01 PM, Johannes Schlüter
> 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/
On 29 בינו 2013, at 17:45, "Ángel González" wrote:
> On 29/01/13 15:21, Pierre Joye wrote:
>> On Tue, Jan 29, 2013 at 3:16 PM, Zeev Suraski wrote:
>>> 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 hand
On Tue, Jan 29, 2013 at 4:43 PM, Ángel González wrote:
> On 29/01/13 15:21, Pierre Joye wrote:
>> On Tue, Jan 29, 2013 at 3:16 PM, Zeev Suraski wrote:
>>> 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 h
On 29/01/13 15:21, Pierre Joye wrote:
> On Tue, Jan 29, 2013 at 3:16 PM, Zeev Suraski wrote:
>> 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
On Tue, 29 Jan 2013, Zeev Suraski wrote:
> 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 th
On Tue, 2013-01-29 at 14:18 +0100, Pierre Joye wrote:
>
>
> 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 th
On Tue, Jan 29, 2013 at 3:16 PM, Zeev Suraski wrote:
>> -Original Message-
>> From: Pierre Joye [mailto:pierre@gmail.com]
>> Sent: Tuesday, January 29, 2013 3:37 PM
>> To: Rasmus Lerdorf
>> Cc: PHP internals
>> Subject: Re: [PHP-DEV] ZTS - why ar
> -Original Message-
> From: Pierre Joye [mailto:pierre@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
>
> -Original Message-
> From: Pierre Joye [mailto:pierre@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?
>
> On Tue, Jan 29, 2013 at 1:52
On Tue, Jan 29, 2013 at 2:33 PM, Rasmus Lerdorf 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
On 01/29/2013 05:18 AM, Pierre Joye wrote:
> 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, me
On Tue, Jan 29, 2013 at 1:52 PM, Zeev Suraski wrote:
>> -Original Message-
>> From: Pierre Joye [mailto:pierre@gmail.com]
>> Sent: Tuesday, January 29, 2013 2:19 PM
>> To: Zeev Suraski
>> Cc: Johannes Schlüter; PHP internals
>> Subject: Re:
29, 2013 2:19 PM
>> To: Zeev Suraski
>> Cc: Johannes Schlüter; PHP internals
>> Subject: Re: [PHP-DEV] ZTS - why are you using it?
>>
>> On Tue, Jan 29, 2013 at 1:06 PM, Zeev Suraski wrote:
>>
>> >> It is inter process sharing and is very expensive, n
> -Original Message-
> From: Pierre Joye [mailto:pierre@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?
>
> On Tue, Jan 29, 2013 at 1:06
On Tue, Jan 29, 2013 at 1:06 PM, Zeev Suraski wrote:
>> 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 reg
On Tue, Jan 29, 2013 at 1:01 PM, Johannes Schlüter
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/59353
>
> Such bugs identified a year after the release of 5.4 giv
On Tue, Jan 29, 2013 at 1:15 PM, Pierre Joye wrote:
>
>
> On Jan 29, 2013 12:10 PM, "Zeev Suraski" wrote:
> >
> > > 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. S
> -Original Message-
> From: Pierre Joye [mailto:pierre@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, Jo
On Tue, 2013-01-29 at 12:49 +0100, Pierre Joye wrote:
> > 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 o
On Tue, Jan 29, 2013 at 12:36 PM, Zeev Suraski wrote:
>> 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.
>
>
> Of course everything that is Windows native uses threads, b
hi,
On Tue, Jan 29, 2013 at 12:45 PM, Johannes Schlüter
wrote:
> On Tue, 2013-01-29 at 12:15 +0100, Pierre Joye 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
> P
On Tue, 2013-01-29 at 12:15 +0100, Pierre Joye 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 sh
> (*) 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
On Jan 29, 2013 12:10 PM, "Zeev Suraski" wrote:
>
> > 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 outper
On Tue, 2013-01-29 at 12:05 +0100, Johannes Schlüter wrote:
> exploit some of the bugs (, 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.
> 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/
On Tue, 2013-01-29 at 11:03 +0200, Zeev Suraski wrote:
> 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.
On Tue, Jan 29, 2013 at 10:56 AM, Pierre Joye wrote:
> 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 lin
hi Zeev,
On Tue, Jan 29, 2013 at 10:03 AM, Zeev Suraski wrote:
> 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
> significa
On Tue, Jan 29, 2013 at 5:35 PM, Zeev Suraski wrote:
>> 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 Fas
> 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
On Tue, Jan 29, 2013 at 5:28 PM, Laruence wrote:
> On Tue, Jan 29, 2013 at 5:03 PM, Zeev Suraski wrote:
>> 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
On Tue, Jan 29, 2013 at 5:03 PM, Zeev Suraski wrote:
> 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.
>
On Tue, Jan 29, 2013 at 1:03 PM, Zeev Suraski wrote:
> 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 ro
On 2013/1/29 17:03, Zeev Suraski wrote:
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 backgroun
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 in
54 matches
Mail list logo
