On Wed, Jan 30, 2013 at 12:49 AM, Stas Malyshev <smalys...@sugarcrm.com> 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 > 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 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. 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: https://wiki.php.net/rfc/tls > - 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
