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.
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
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.-----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? ...
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
Johannes,
Thanks, but I'll make some responses
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"
platformsAnd 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.
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.
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.
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 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.
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
<snip> Terry Ellison wrote:
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.
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:
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
<snip> Terry Ellison wrote:
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.
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
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