# Which OSs and SAPI should PHP 5.6 support? - Thread: https://externals.io/message/68565 - Original archive: https://news-web.php.net/php.internals/68565 - Started by Terry Ellison on 2013-08-19T16:05:14+00:00 - Messages: 9 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #68565 — Terry Ellison — 2013-08-19T16:05:14+00:00 URL: https://externals.io/message/68565#68565 By way of a background. I've been doing a review of the exting code base looking at how to establishing a roadmap extend OPcache functionality across all supported OSes and SAPIs. And this raises a supplementary Q: which OSs and SAPIs should we be supporting for PHP 5.6 anyway? I would be interested in the views of the dev team on this. It would be good to agree a list of which OSs are to be supported at PHP 5.6, which SAPIs are supported, and a matrix of which SAPIs are supported on non-threaded and build TSRM variants. Examples of what I am talking about are SAPIs with no clear evidence of active support (I've listed the last non-bulk change in brackets to give a measure of the level of support): aolserver (2008), caudium (2005), continuity (2004), nsapi (2011), phttpd (2002), pi3web (2003), roxon (2002), thttpd (2002), tux (2007), webjames (2006) I realise that some of these may still be actively used with a user community out there wanting to track current versions, and this is just a case of "if ain't broke..." However, I do wonder when some of these were actively maintained and routinely tested against the current versions at release -- and if not then perhaps PHP 5.6 is the correct point to retire them from the source tarball and configure options? Likewise in the Zend, TSRM, ext/opcache ... sources, there is conditional code dependent on BeOS, __sgi, __osf__, __IRIX__, NSAPI, PI3WEB, GNUPTH(*), OS_VXWORKS, etc. as well as obsolete BSD versions -- OSs that are no longer actively supported. Again I ask the Q how and when are these tested and if not then shouldn't we retire this support? Part of my reasons for asking this is work in preparation for OPcache issue #118 -- Transparent SHM reuse. Doing this with robustly with good performance characteristics -- for *all* currently referenced OSs -- is a pain. Reviewing a range of other best-of breed packages which use shared SMA-based resources, it seems to me that the memcached approach is the cleanest: it uses the POSIX APIs and supports any OSes which support these APIs. If we limited TSRM and OPcache support at PHP 5.6 to two code variants, POSIX + WIN32, surely this would still cover all the major supported OSes? //Terry Ellison (*) GNU threads is still supported but it prevents utilisation of SMP systems and there is a minimal performance differences from POSIX threads on a single processor system. --- ## #68567 — Uwe Schindler — 2013-08-19T16:20:15+00:00 URL: https://externals.io/message/68565#68567 · In reply to: #68565 Hi, I would update NSAPI as I always did, there were just no new bugs and code is very stable (to the extend of "stableness" of multithreaded SAPIs). It is still also in use on some of my servers, so I would still help support it. At the moment I did not follow recent commits to SAPI-related code, so I have to closer look into it. Are there any RFCs related to changes coming in 5.6 for OPcache? Unfortunately I did not do any commit since we moved away from SVN... Uwe ----- Uwe Schindler thetaphi@php.net - http://www.php.net NSAPI SAPI developer Bremen, Germany > -----Original Message----- > From: Terry Ellison [mailto:ellison.terry@gmail.com] > Sent: Monday, August 19, 2013 6:05 PM > To: internals@lists.php.net > Subject: [PHP-DEV] Which OSs and SAPI should PHP 5.6 support? > > By way of a background. I've been doing a review of the exting code base > looking at how to establishing a roadmap extend OPcache functionality > across all supported OSes and SAPIs. And this raises a supplementary Q: > which OSs and SAPIs should we be supporting for PHP 5.6 anyway? I would > be interested in the views of the dev team on this. > > It would be good to agree a list of which OSs are to be supported at PHP 5.6, > which SAPIs are supported, and a matrix of which SAPIs are supported on > non-threaded and build TSRM variants. > > Examples of what I am talking about are SAPIs with no clear evidence of > active support (I've listed the last non-bulk change in brackets to give a > measure of the level of support): > aolserver (2008), caudium (2005), continuity (2004), nsapi (2011), > phttpd (2002), pi3web (2003), roxon (2002), thttpd (2002), > tux (2007), webjames (2006) > I realise that some of these may still be actively used with a user community > out there wanting to track current versions, and this is just a case of "if ain't > broke..." However, I do wonder when some of these were actively > maintained and routinely tested against the current versions at release -- and > if not then perhaps PHP 5.6 is the correct point to retire them from the > source tarball and configure options? > > Likewise in the Zend, TSRM, ext/opcache ... sources, there is conditional > code dependent on BeOS, __sgi, __osf__, __IRIX__, NSAPI, PI3WEB, > GNUPTH(*), OS_VXWORKS, etc. as well as obsolete BSD versions -- OSs that > are no longer actively supported. Again I ask the Q how and when are these > tested and if not then shouldn't we retire this support? > > Part of my reasons for asking this is work in preparation for OPcache issue > #118 -- Transparent SHM reuse. Doing this with robustly with good > performance characteristics -- for *all* currently referenced OSs -- is a pain. > Reviewing a range of other best-of breed packages which use shared SMA- > based resources, it seems to me that the memcached approach is the > cleanest: it uses the POSIX APIs and supports any OSes which support these > APIs. If we limited TSRM and OPcache support at PHP 5.6 to two code > variants, POSIX + WIN32, surely this would still cover all the major supported > OSes? > > //Terry Ellison > > (*) GNU threads is still supported but it prevents utilisation of SMP systems > and there is a minimal performance differences from POSIX threads on a > single processor system. > > -- > To unsubscribe, visit: > http://www.php.net/unsub.php --- ## #68568 — Terry Ellison — 2013-08-19T17:06:40+00:00 URL: https://externals.io/message/68565#68568 · In reply to: #68567 Uwe Schindler wrote: > I would update NSAPI as I always did, there were just no new bugs and code is very stable (to the extend of "stableness" of multithreaded SAPIs). It is still also in use on some of my servers, so I would still help support it. UWE, If its used on some of your servers, and you are supporting it then it doesn't belong on my suggested list. :-) > At the moment I did not follow recent commits to SAPI-related code, so I have to closer look into it. Are there any RFCs related to changes coming in 5.6 for OPcache? Not currently. > > […] --- ## #68570 — johannes@schlueters.de — 2013-08-19T19:51:48+00:00 URL: https://externals.io/message/68565#68570 · In reply to: #68565 > By way of a background. I've been doing a review of the exting code > base looking at how to establishing a roadmap extend OPcache > functionality across all supported OSes and SAPIs. And this raises a > supplementary Q: which OSs and SAPIs should we be supporting for PHP 5.6 > anyway? I would be interested in the views of the dev team on this. > > It would be good to agree a list of which OSs are to be supported at PHP The short version is quite simple: PHP supports everything and nothing. Our aim is to be portable and have it running anywhere somebody has a C compiler and the required libs. On the other hand, in open source spirit, we promise nothing. In reality I expect that most developers use Linux and we have a active Windows fraction. If we promise support for any platform it has two direct consequences: - We have to test and verify it - We immediately disappoint people who run PHP successfully on "edge" platforms And then more longterm consequences: - Mind new platforms - Continuous discussions about adding support for new platforms The current model otoh works quite well. > 5.6, which SAPIs are supported, and a matrix of which SAPIs are > supported on non-threaded and build TSRM variants. I myself would kill TSRM, but others have reasons to disagree ;-) In general: There are features which are dependent on operating system, 3rd party library or TSRM. This is fine. Based on my statement from above I claim (again, there are people who disagree for reasons I follow less than the general case above) that nobody who cares about performance uses TSRM, as such an opcode cache is not needed in such environments. > Examples of what I am talking about are SAPIs with no clear evidence of > active support (I've listed the last non-bulk change in brackets to give > a measure of the level of support): > aolserver (2008), caudium (2005), continuity (2004), nsapi (2011), > phttpd (2002), pi3web (2003), roxon (2002), thttpd (2002), > tux (2007), webjames (2006) > I realise that some of these may still be actively used with a user > community out there wanting to track current versions, and this is just > a case of "if ain't broke..." However, I do wonder when some of these > were actively maintained and routinely tested against the current > versions at release -- and if not then perhaps PHP 5.6 is the correct > point to retire them from the source tarball and configure options? First thing to note is that the SAPI layer is one of the most stable ones. So old SAPIs most likely work. Secondly: Yes some of them almost certainly can go, when we discussed this last (~10 years ago) an issue was that we have no good place to put these. For extensions we have Siberia^H^H^H^H^HPECL where people can try if they get it working ... getting SAPIs work from out of tree is not as easy ... johannes --- ## #68582 — Terry Ellison — 2013-08-20T15:34:31+00:00 URL: https://externals.io/message/68565#68582 · In reply to: #68570 Johannes, Thanks, but I'll make some responses > > > […] > The short version is quite simple: PHP supports everything and nothing. > > Our aim is to be portable and have it running anywhere somebody has a C compiler and the required libs. On the other hand, in open source spirit, we promise nothing. > > In reality I expect that most developers use Linux and we have a active Windows fraction. > > If we promise support for any platform it has two direct consequences: > - We have to test and verify it > - We immediately disappoint people who run PHP successfully on "edge" > platforms > > And then more longterm consequences: > - Mind new platforms > - Continuous discussions about adding support for new platforms > > The current model otoh works quite well. I understand the nuances of what "support" means in the FLOSS world, but at some level we also be able to look at ourselves in the mirror and say that are releases are at a standard that we can feel comfortable with. As you say, we have an established Linux base as well as some Windows. I would also add a solid BSD user base (FreeBSD, NetBSD, OSX, etc.). (Maybe I'd include Solaris, but it's on the way out given Oracle's position.) But what about all of the other obsolete platform code? We ship this with our PHP source, version after version, knowing that its never being exercised or tested. Surely if and when we want to improve PHP's platform support and architecture, then this stuff is like chains dragging at out feet. For example, I know how to make OPcache work well for other SAPIs such as cli, mod_fcgid, etc. but only if I can refactor the necessary chunks and only for POSIX and Win32 which covers the platforms we've just discussed; worrying about of the other flavours that I could never test just gives me too much brain ache, but I can't propose a code refactor if I don't know what to do with it. PHP (unlike some language alternatives) seems to be doing little to improve general performance, and the discussions related to performance on this DL are almost non-existent. > > […] > I myself would kill TSRM, but others have reasons to disagree ;-) > > In general: There are features which are dependent on operating system, 3rd party library or TSRM. This is fine. Based on my statement from above I claim (again, there are people who disagree for reasons I follow less than the general case above) that nobody who cares about performance uses TSRM, as such an opcode cache is not needed in such environments. Yes, if the Zend engine had first been developed for Windows, then it would have supported proper multi-threading from Day 1. It wasn't, so TSRM is a cludge to achieve this. Dmitry made the comment somewhere that enabling TSRM incurs a ~20% performance hit, which I can believe, but as far as I can see, WIN32 implementations rely on it for scaling. Looking at fpm, cgi, etc. all of the SAPIs which rely on a master/child process hierarchies for scaling use fork, and they all have a big #ifndef ZEND_WIN32 around this code. OK, CreateProcess incurs more startup overhead than forking and there are other startup issues to address relating to acquisition of context, but I've written serious realtime systems for WIN32 in the past that performed well without threads. So I am not sure why this is the case. However the lack of OPcode caching on complex apps typically halves system throughput. Most if not all admins care about that sort of hit. > > […] > First thing to note is that the SAPI layer is one of the most stable ones. So old SAPIs most likely work. > Secondly: Yes some of them almost certainly can go, when we discussed this last (~10 years ago) an issue was that we have no good place to put these. For extensions we have PECL where people can try if they get it working ... getting SAPIs work from out of tree is not as easy ... How about the great bit bucket? Surely there's no point in distributing a SAPI if we have no maintainers or sysadmins left who are willing to move their legacy apps on their out-of-support OSs, from whatever version they are running -- say PHP 5.2 -- to the current version. --- ## #68583 — johannes@schlueters.de — 2013-08-20T15:50:18+00:00 URL: https://externals.io/message/68565#68583 · In reply to: #68582 Hi, I'll get back on the other things later, but a short comment (flaming) on this: > > PHP (unlike some language alternatives) seems to be doing little to > improve general performance, and the discussions related to > performance on this DL are almost non-existent. Looking at any benchmark from 5.2 to 5.3 to 5.4 and 5.5 shows notable improvements (5.4 to 5.5 maybe not as much as the others) saying we do little is a bit misleading. But well, it is simpler to do these syntax sugar things we're bikeshedding about than doing actual core improvements. We have just very few people fully understanding the engine and being able to improve it. So such discussions gain no traction. johannes --- ## #68584 — Terry Ellison — 2013-08-20T16:17:38+00:00 URL: https://externals.io/message/68565#68584 · In reply to: #68583 > Terry Ellison wrote: > > […] > Looking at any benchmark from 5.2 to 5.3 to 5.4 and 5.5 shows notable > improvements (5.4 to 5.5 maybe not as much as the others) saying we do > little is a bit misleading. > > But well, it is simpler to do these syntax sugar things we're > bikeshedding about than doing actual core improvements. We have just > very few people fully understanding the engine and being able to improve > it. So such discussions gain no traction. I apologise if this sounded as unreasonably critical, as this wasn't my intent. As it happens, my particular interest is in PHP performance and I've got a good understanding of the Zend Engine and opcache, but trying to work out how I can contribute effectively to this is difficult for me given this lack of traction. I also know that Dmitry and you guys made some fundamental improvements to the 5.4 engine that significantly dropped the op_array sizing and lead to perhaps an overall 5-15% performance improvement. I discussed this in some depth on my OPcache documentation on this page: https://github.com/TerryE/opcache/wiki/The-Zend-Engine-and-opcode-caching#wiki-Comments_on_Zend_engine_performance However, I don't think that this is appreciated in the wider PHP community (for example I can't recall it ever being discussed or emphasised on StackOverflow). I feel that it got lost in the reaction to APC not working reliably with the early 5.4 dot releases. Regards Terry --- ## #68585 — johannes@schlueters.de — 2013-08-20T16:43:28+00:00 URL: https://externals.io/message/68565#68585 · In reply to: #68584 > > > > […] > I apologise if this sounded as unreasonably critical, as this wasn't > my intent. As it happens, my particular interest is in PHP > performance and I've got a good understanding of the Zend Engine and > opcache, but trying to work out how I can contribute effectively to > this is difficult for me given this lack of traction. If you have to apologize I held back too much on syntax sugar bikeshed discussion flaming :-D > However, I don't think that this is appreciated in the wider PHP > community (for example I can't recall it ever being discussed or > emphasised on StackOverflow). I feel that it got lost in the reaction > to APC not working reliably with the early 5.4 dot releases. Well performance was discussed in the 5.3 time a bit, 5.4 never really got traction as, frankly, it doesn't provide notable new features and so people stay with distributions, which were just getting to 5.3 when 5.4 came out. (just looking at the news file to remember, 5.4 were traits, great feature, but very specialized and then "syntax sugar" like short array syntax, Class::{expr}(), callable, ... they are nice, but nothing demanding a version upgrade, "nobody" would break 5.3 compatibility just for using them) AND, frankly, performance is no reason for most™ users to upgrade - PHP for most™, is fast enough. And for many of those for who it is too slow the performance issue actually isn't in PHP, but external IO (databases etc.). If you look at your typical Drupal site where 80% or so is spent in database (thanks to all the fancy modules you have) we can improve PHP performance by unrealistic 50% and still just hardly see an overall win. Sure there are many "power users" who need more but those don't create such a buzz, they do their business. (and as you mentioned stackoverflow - such places are crowded by people who try to get their copy&pasted "code" working it's already hard to find the medium level questions there ...) Anyways, this is all off topic in this thread and better belongs to a pub while having a beer or such in ones hand ;-) johannes --- ## #68587 — Jan Ehrhardt — 2013-08-20T18:40:44+00:00 URL: https://externals.io/message/68565#68587 · In reply to: #68584 Terry Ellison in php.internals (Tue, 20 Aug 2013 17:17:38 +0100): >However, I don't think that this is appreciated in the wider PHP >community (for example I can't recall it ever being discussed or >emphasised on StackOverflow). In the Windows world performance certainly was a topic. I suspect Pierre was frowning a little bit when he was reading "The team here at Microsoft has been busy preparing PHP 5.5.0", but it is true that PHP 5.5 on Windows is the fastest Windows-PHP yet: http://blog.syntaxc4.net/post/2013/06/20/php-5-5-0-for-windows-released.aspx Jan