Johannes,
Thanks, but I'll make some responses
On Mon, 2013-08-19 at 17:05 +0100, Terry Ellison wrote:
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.
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.
