> -----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 PM, Zeev Suraski <z...@zend.com> 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: [PHP-DEV] ZTS - why are you using it? > >> > >> On Tue, Jan 29, 2013 at 1:06 PM, Zeev Suraski <z...@zend.com> 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 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
