# [RFC] Integrating Zend Optimizer+ into the PHP distribution - Thread: https://externals.io/message/65321 - Original archive: https://news-web.php.net/php.internals/65321 - Started by Zeev Suraski on 2013-01-29T08:03:57+00:00 - Messages: 77 - Page 1 of 4: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/65321.md?page=2 - 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 --- ## #65321 — Zeev Suraski — 2013-01-29T08:03:57+00:00 URL: https://externals.io/message/65321#65321 All, Following the discussion at the end of last week, I prepared a draft RFC for the inclusion of Optimizer+ in PHP. In parallel we’re in the process of prepping the source code for independent public consumption, which I hope we can be done with by the end of next week, hopefully sooner. https://wiki.php.net/rfc/optimizerplus Comments welcome! Zeev --- ## #65322 — Pierre Joye — 2013-01-29T08:07:13+00:00 URL: https://externals.io/message/65321#65322 · In reply to: #65321 hi Zeev! > All, > > > > Following the discussion at the end of last week, I prepared a draft RFC > for the inclusion of Optimizer+ in PHP. > > In parallel we’re in the process of prepping the source code for > independent public consumption, which I hope we can be done with by the end > of next week, hopefully sooner. Thanks! > https://wiki.php.net/rfc/optimizerplus > > > > Comments welcome! One important part missing is the actual compatibility/support of thread safe PHP. I know that Zend mostly care about NTS since quite some time and that worries me a lot to bundle something that is not working well in thread safe mode. I would consider that as a stopping point. I mean, not to stop its inclusion, but to release 5.5.0 with it without optimizer working as good as APC in ts mode. Cheers, -- Pierre @pierrejoye --- ## #65324 — Ryan McCue — 2013-01-29T08:12:53+00:00 URL: https://externals.io/message/65321#65324 · In reply to: #65321 Zeev Suraski wrote: > Following the discussion at the end of last week, I prepared a draft RFC > for the inclusion of Optimizer+ in PHP. Hey Zeev, I see in the Benchmarks you tested with WordPress 2.1.1, however this release is roughly 5 years old. Is it possible to get an updated test with 3.5.1 (the latest release)? (My guess is that it will show WP being slower and with a more dramatic improvement.) Thanks, -- Ryan McCue One important part missing is the actual compatibility/support of thread safe > PHP. I know that Zend mostly care about NTS since quite some time and that > worries me a lot to bundle something that is not working well in thread safe > mode. I would consider that as a stopping point. I mean, not to stop its inclusion, > but to release 5.5.0 with it without optimizer working as good as APC in ts > mode. It's mentioned in the RFC - but I think we should be able to (re)add NTS support pretty quickly. Zeev --- ## #65326 — Laruence — 2013-01-29T08:23:09+00:00 URL: https://externals.io/message/65321#65326 · In reply to: #65321 > All, > > > > Following the discussion at the end of last week, I prepared a draft RFC > for the inclusion of Optimizer+ in PHP. > > In parallel we’re in the process of prepping the source code for > independent public consumption, which I hope we can be done with by the end > of next week, hopefully sooner. Thanks! It's great. however, it's a little not perfect that no ZTS supports. :) > > > > https://wiki.php.net/rfc/optimizerplus > > > > Comments welcome! > > > > Zeev -- Laruence Xinchen Hui http://www.laruence.com/ --- ## #65327 — Laruence — 2013-01-29T08:25:05+00:00 URL: https://externals.io/message/65321#65327 · In reply to: #65325 > > […] > safe > > […] > that > > […] > safe > > […] > inclusion, > > […] > ts > > […] > > It's mentioned in the RFC - but I think we should be able to (re)add NTS > support pretty quickly. Hey: my problem gone. ignore my previous mail thanks > > Zeev > > -- > > > -- Laruence Xinchen Hui http://www.laruence.com/ --- ## #65328 — Zeev Suraski — 2013-01-29T08:30:57+00:00 URL: https://externals.io/message/65321#65328 · In reply to: #65324 > -----Original Message----- > From: Ryan McCue [mailto:lists@rotorised.com] > Sent: Tuesday, January 29, 2013 10:13 AM > To: Zeev Suraski > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP > distribution > > Zeev Suraski wrote: > > […] > > Hey Zeev, > > I see in the Benchmarks you tested with WordPress 2.1.1, however this > release > is roughly 5 years old. Is it possible to get an updated test with 3.5.1 > (the latest > release)? You'd notice the entire test suite is more than a bit old :) It's been our standard test suite for years so that we can keep comparing apples to apples. We can definitely run tests on newer versions - and once we open it up I think it'd be great if people contribute some of their own benchmarks! > (My guess is that it will show WP being slower and with a more dramatic > improvement.) By the way, I just realized the % gain wasn't all that self-explanatory - it's vs. APC, not vs. plain PHP. I improved the doc to reflect both gains vs. plain PHP and vs. APC. Thanks for the feedback! Zeev --- ## #65329 — Ivan Enderlin @ Hoa — 2013-01-29T08:33:26+00:00 URL: https://externals.io/message/65321#65329 · In reply to: #65328 > [snip] > > […] > By the way, I just realized the % gain wasn't all that self-explanatory - > it's vs. APC, not vs. plain PHP. I improved the doc to reflect both gains > vs. plain PHP and vs. APC. It's better now ;-). Thank you for the contribution. It's a great news! Can APC and Optimizer+ work in duo or share some features? -- Ivan Enderlin Developer of Hoa http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ --- ## #65330 — Laruence — 2013-01-29T08:38:02+00:00 URL: https://externals.io/message/65321#65330 · In reply to: #65329 On Tue, Jan 29, 2013 at 4:33 PM, Ivan Enderlin @ Hoa wrote: > > > […] > > It's better now ;-). > > Thank you for the contribution. It's a great news! Can APC and Optimizer+ > work in duo or share some features? If O+ became opensource, I think it can be done by lots contributors.. :) thanks > > -- > Ivan Enderlin > Developer of Hoa > http://hoa-project.net/ > > PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) > http://disc.univ-fcomte.fr/ and http://www.inria.fr/ > > Member of HTML and WebApps Working Group of W3C > http://w3.org/ > > > > -- > > > -- Laruence Xinchen Hui http://www.laruence.com/ --- ## #65331 — netroby — 2013-01-29T08:51:50+00:00 URL: https://externals.io/message/65321#65331 · In reply to: #65330 > On Tue, Jan 29, 2013 at 4:33 PM, Ivan Enderlin @ Hoa > wrote: > > […] > If O+ became opensource, I think it can be done by lots contributors.. :) > > thanks > > […] > > Good news, if Optimizer+ will be integrated to PHP, that's amazing improvement. I vote: Integrate Optimizer+ intoPHP5.5.0, allow up to 2 months delay why we could waiting ? because PHP 5.4 is stable for production environment. we could wait for more bit long time. the big improvement is better than fast release. we do not need release for release. no sense. why not take us some surprise. -- Appreciate your time. ---------------------------- Netroby --- ## #65339 — Martin Keckeis — 2013-01-29T09:47:43+00:00 URL: https://externals.io/message/65321#65339 · In reply to: #65331 From the perspective of the end-user this would be really great! If it could really be done in 2 months -> wait for it. best regards. --- ## #65343 — Victor Berchet — 2013-01-29T10:05:49+00:00 URL: https://externals.io/message/65321#65343 · In reply to: #65339 > From the perspective of the end-user this would be really great! > If it could really be done in 2 months -> wait for it. > Why should we break the PHP release process by 2 months+ to include O+ ? There are alternatives (APC to name one) and O+ might also be used on top of the core (I don't know it to be able to tell). I think waiting 10 months (12-2) is preferrable and O+ would go in the next PHP release (if accepted). There is really no point in delaying a relase for a feature (vs a bug fix) - even more when substitutes exist. My 2 cents, Victor --- ## #65345 — Florin Razvan Patan — 2013-01-29T10:26:06+00:00 URL: https://externals.io/message/65321#65345 · In reply to: #65321 Thank you for this great initiative! As a user, I could definitely wait for 2-3 more months and get a good implementation/integration of this rather that have to wait for at least one year. I think it would also be nice if this could come as default enabled since this way people would be able to notice the advantages of having it enabled. Or you can run a survey on php.net to see what are the options. I do have one thing to ask you about this. If we do wait 2 months, will the underlaying changes be able to integrate easy with APC/XCache/eAccelerator/others? Opcodes are a must for large traffic websites like those I'm working on right now, so we clearly want to have such a thing installed on our servers as soon as we install a new PHP version. But if including O+ will mean that APC gets delayed 6+ months (see PHP 5.4) it would be a show stopper for us upgrading to PHP 5.5. Our upgrade process is like this: be at least one year on market to iron out major/obvious bugs. If APC gets on the market 6 months after PHP 5.5 only because of this then we'll be near PHP 5.6 by then. And we can't just change from APC to others as we'll need to test them as well as see which other use data caching like APC has. It would make sense to actually see how the whole ZE can be improved so that it makes life of opcode cachers easier and then ship O+ bundled with a PHP version that has better support for them out of the box if I were to choose. Best regards, Florin ---- Florin Patan https://github.com/dlsniper > All, > > > > Following the discussion at the end of last week, I prepared a draft RFC > for the inclusion of Optimizer+ in PHP. > > In parallel we’re in the process of prepping the source code for > independent public consumption, which I hope we can be done with by the end > of next week, hopefully sooner. > > > > https://wiki.php.net/rfc/optimizerplus > > > > Comments welcome! > > > > Zeev --- ## #65346 — Tyler Sommer — 2013-01-29T10:37:17+00:00 URL: https://externals.io/message/65321#65346 · In reply to: #65321 This is really exciting! As a user, I say allow a delay to get this into 5.5. I was kind of disappointed that some cache wasn't bundled with 5.4. It's been too long that this very important piece has been separate from the core. Cheers --- ## #65356 — Anthony Ferrara — 2013-01-29T11:23:27+00:00 URL: https://externals.io/message/65321#65356 · In reply to: #65346 Zeev, First off, very nice job on the RFC. I definitely like what's happening here. As far as delaying 5.5, I have mixed feelings. I think we should definitely consider the delay, but only in a time-boxed format. So if we say "1 month", then if it's not ready to be committed in that month, it doesn't get in and we release 5.5 anyway. I don't think we should do an indefinite (not hard-defined) delay, as we could wind up in a situation similar to 6, where for some reason we wind up delayed for 6 months or worse. I'm not saying I think it'll happen, but we should be careful to limit it. In addition, I would suggest putting in a feature freeze for everything except this feature as well. Not because we shouldn't have new features, but to prevent another "everyone wants this, so let's delay some more" feature 1 week before the timebox expires. Additionally, I don't like the precedent that this sets for future releases. That it's ok to break the timebox for some feature. In this case I think we can justify it, but future cases may use this to justify waiting when it's not completely justified in itself. I'm not sure how we can rectify this concern, but I figured it was worth mentioning. Anthony > This is really exciting! > > As a user, I say allow a delay to get this into 5.5. I was kind of > disappointed that some cache wasn't bundled with 5.4. It's been too long > that this very important piece has been separate from the core. > > > Cheers --- ## #65358 — Ferenc Kovacs — 2013-01-29T11:32:18+00:00 URL: https://externals.io/message/65321#65358 · In reply to: #65345 On Tue, Jan 29, 2013 at 11:26 AM, Florin Razvan Patan wrote: > Thank you for this great initiative! > > As a user, I could definitely wait for 2-3 more months and get > a good implementation/integration of this rather that have to > wait for at least one year. > > I think it would also be nice if this could come as default > enabled since this way people would be able to notice the > advantages of having it enabled. Or you can run a survey on > php.net to see what are the options. > > I do have one thing to ask you about this. > > If we do wait 2 months, will the underlaying changes be able > to integrate easy with APC/XCache/eAccelerator/others? > > Opcodes are a must for large traffic websites like those I'm > working on right now, so we clearly want to have such a thing > installed on our servers as soon as we install a new PHP > version. But if including O+ will mean that APC gets delayed > 6+ months (see PHP 5.4) it would be a show stopper for us > upgrading to PHP 5.5. > > Our upgrade process is like this: be at least one year on market > to iron out major/obvious bugs. If APC gets on the market 6 > months after PHP 5.5 only because of this then we'll be near > PHP 5.6 by then. And we can't just change from APC to others > as we'll need to test them as well as see which other use data > caching like APC has. > > It would make sense to actually see how the whole ZE can > be improved so that it makes life of opcode cachers easier > and then ship O+ bundled with a PHP version that has better > support for them out of the box if I were to choose. > > > please don't top on this list, we prefer bottom or inline posting around here, see http://www.php.net/reST/README.MAILINGLIST_RULES back to the topic: personally I think that even two months seems like a tight schedule as we are talking about incorporating an opcode cache, which I'm pretty sure that it is similar in complexity to apc, and are only like a handful of people on the planet has any experience working with, and needs some polishing and has at least one known shortcoming (thread safety). my opinion is that we should wait for the code to be released before thinking about the release dates. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #65372 — Leigh — 2013-01-29T13:14:13+00:00 URL: https://externals.io/message/65321#65372 · In reply to: #65356 > Zeev, > > First off, very nice job on the RFC. I definitely like what's happening > here. > > As far as delaying 5.5, I have mixed feelings. I think we should definitely > consider the delay, but only in a time-boxed format. So if we say "1 > month", then if it's not ready to be committed in that month, it doesn't > get in and we release 5.5 anyway. Do you really think a month would be enough (we're talking implementation and really thorough testing)? We're fast approaching beta and the feature freeze, and this is by no means a small feature (correct me if I am mistaken). I think this would very much benefit from the time between releases to get it really thoroughly integrated and tested. Far more eyes will see it, and contribute to it in the time between 5.5 and 5.6 than if it is rushed for 5.5. Stability is king when it comes to adoption, and we really don't need an edge case coming up at the last minute that gives people another reason not to upgrade. In addition, I would suggest putting in a feature freeze for everything > except this feature as well. Not because we shouldn't have new features, > but to prevent another "everyone wants this, so let's delay some more" > feature 1 week before the timebox expires. > That would allow more focused testing and development on this specific feature, but... > Additionally, I don't like the precedent that this sets for future > releases. .. this. There has already been a couple of discussions this week around "rule bending" (voting / bc breaks). I think the release schedule is an important one to stick to. Is it possible to introduce O+ via PECL in the interim? --- ## #65377 — Kalle Sommer Nielsen — 2013-01-29T13:27:40+00:00 URL: https://externals.io/message/65321#65377 · In reply to: #65321 Hi Zeev 2013/1/29 Zeev Suraski : > In parallel we’re in the process of prepping the source code for > independent public consumption, which I hope we can be done with by the end > of next week, hopefully sooner. I'm sorry, but I don't see why we out of a sudden should consider adding a Zend product to the core, over that we got already, yes I'm pointing in APC's direction, although it is in PECL. I'm not trying to bring in this skepticism here because I'm, a previous APC dev, but mostly because I do not think this is the right move. Why? Because we tried to push APC from PECL into the Core since early 5.x, although I've only been around since just before 5.3a1, I remember how we were all focused on putting APC into the Core rather than a non php.net project (like XCache, eAccelerator, ...), where many of the core developers have invested much time in promoting APC, and tried to fix some of the issues it have had. Moving APC into the core was against some people's PoV because they thought it would be enabled by default, which it wouldn't be at all. I am very strongly against this move if its approved (not the actual RFC), but how an outside product suddenly deserves a spot in the core over our own code, by that I mean folks that does not work for Zend, but have contributed the code to php.net, I think that is highly controversial. -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #65378 — Pierre Joye — 2013-01-29T13:30:05+00:00 URL: https://externals.io/message/65321#65378 · In reply to: #65377 > Hi Zeev > > 2013/1/29 Zeev Suraski : > > […] > > I'm sorry, but I don't see why we out of a sudden should consider > adding a Zend product to the core, over that we got already, yes I'm > pointing in APC's direction, although it is in PECL. > I'm not trying to bring in this skepticism here because I'm, a > previous APC dev, but mostly because I do not think this is the right > move. Why? Because we tried to push APC from PECL into the Core since > early 5.x, It is not done yet. But given that the code is clean and easily maintainable, it could be much more efficient for us to focus on one extension and make it rock instead of trying to get each of them work well. As Rasmus stated, between the opcode/engine and the way such extensions work, we only have a handful of developers able to work on them, and not full time. Cheers, -- Pierre @pierrejoye --- ## #65379 — Clint Priest — 2013-01-29T13:30:19+00:00 URL: https://externals.io/message/65321#65379 · In reply to: #65356 > Additionally, I don't like the precedent that this sets for future > releases. That it's ok to break the timebox for some feature. In this case > I think we can justify it, but future cases may use this to justify waiting > when it's not completely justified in itself. I'm not sure how we can > rectify this concern, but I figured it was worth mentioning. I would agree with this sentiment, time boxing from my own personal experience just completely breaks down if you let anything get in the way of it, if you let that box slip for any reason, other reasons become easily justifyable. If 5.5 is due for release, we should not delay it for 2 months to get an opcode cache into core. Additionally: 1) I believe Optimizer+ is the opcode cache that's been discussed but it's not thread safe? 2) Isn't APC the standard? Is it in such bad shape it is not even being considered any longer? 3) There has never been a bundled opcode cache that I'm aware of, one more release without one is not going to surprise many people 4) Waiting for a 5.6 release will give everyone an entire year to get this into core and well tested which based on all the hoopla about how critical APC/opcode caches are to the core it makes sense that integration is going to be a long and painful process. -- -Clint --- ## #65385 — Zeev Suraski — 2013-01-29T13:40:37+00:00 URL: https://externals.io/message/65321#65385 · In reply to: #65377 > -----Original Message----- > From: kalle.php@gmail.com [mailto:kalle.php@gmail.com] On Behalf Of Kalle > Sommer Nielsen > Sent: Tuesday, January 29, 2013 3:28 PM > To: Zeev Suraski > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP > distribution > > Hi Zeev > > 2013/1/29 Zeev Suraski : > > […] > > I'm sorry, but I don't see why we out of a sudden should consider adding a Zend > product to the core, over that we got already, yes I'm pointing in APC's > direction, although it is in PECL. The RFC explains the pros and cons of doing that, I don't really have any additional reasons to add beyond what I already put there. I believe the pros outweigh the cons by a good considerable margin, but that's what the vote would be about. Perhaps the one thing worth adding is that the people who worked on Optimizer+ are all major php.net contributors, including Dmitry, Stas, Andi and myself - it's not some alien artifact. Zeev --- ## #65386 — Kalle Sommer Nielsen — 2013-01-29T13:40:57+00:00 URL: https://externals.io/message/65321#65386 · In reply to: #65378 Hi Pierre 2013/1/29 Pierre Joye : > It is not done yet. But given that the code is clean and easily > maintainable, it could be much more efficient for us to focus on one > extension and make it rock instead of trying to get each of them work > well. As Rasmus stated, between the opcode/engine and the way such > extensions work, we only have a handful of developers able to work on > them, and not full time. I totally agree that having one extension and making it work altogether is better, but the way I see it presented is that Zend wants to lends us a hand if we pick their product, FOSS it and put it into the core, so we got some more people working on it (I won't say full time), but I'm sure that if its a Zend product there are gonna be some more attention to it from their side. -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #65387 — Kalle Sommer Nielsen — 2013-01-29T13:44:57+00:00 URL: https://externals.io/message/65321#65387 · In reply to: #65385 2013/1/29 Zeev Suraski : > The RFC explains the pros and cons of doing that, I don't really have any > additional reasons to add beyond what I already put there. I believe the > pros outweigh the cons by a good considerable margin, but that's what the > vote would be about. Perhaps the one thing worth adding is that the > people who worked on Optimizer+ are all major php.net contributors, > including Dmitry, Stas, Andi and myself - it's not some alien artifact. I don't doubt any of your abilities, what I do doubt is that how we can consider an outside project directly into the core. APC would without a doubt be up to pair if there was more people willingly to dwell into it (yes dwell as many people see it as an alien artifact because it touches and modifies some "unusual" things that the average extension developer don't). -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #65388 — Zeev Suraski — 2013-01-29T13:48:10+00:00 URL: https://externals.io/message/65321#65388 · In reply to: #65379 > -----Original Message----- > From: Clint Priest [mailto:cpriest@zerocue.com] > Sent: Tuesday, January 29, 2013 3:30 PM > To: Anthony Ferrara > Cc: Tyler Sommer; Zeev Suraski; internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP > distribution > > > > […] mentioning. > I would agree with this sentiment, time boxing from my own personal > experience just completely breaks down if you let anything get in the way of it, if > you let that box slip for any reason, other reasons become easily justifyable. If > 5.5 is due for release, we should not delay it for 2 months to get an opcode > cache into core. > > Additionally: > > 1) I believe Optimizer+ is the opcode cache that's been discussed but it's not > thread safe? It's presently not thread safe. Just to be sure we're all on the same page, this is only meaningful if you're running PHP on Windows and not using FastCGI; It's completely meaningless in any other scenario (i.e. for the vast majority of users); That said, adding thread safety support for Optimizer+ is a fairly easy task. We've never done it because none of our commercial products use thread-safe PHP. I'll update the RFC to clarify the scope of this limitation. > 2) Isn't APC the standard? Is it in such bad shape it is not even being considered > any longer? Did you read the RFC? Yes, it is considered, and it's certainly an option on the table, with advantages and disadvantages. There's a whole section in the RFC about it. > 3) There has never been a bundled opcode cache that I'm aware of, one more > release without one is not going to surprise many people > > 4) Waiting for a 5.6 release will give everyone an entire year to get this into core > and well tested which based on all the hoopla about how critical APC/opcode > caches are to the core it makes sense that integration is going to be a long and > painful process. I for one am not very fond of having a release every 12 months, and the current pace of every 18 month seems rapid enough. So we'd be talking about a year and a half, not a year. My opinion is that looking at our adoption patterns, delaying by 2 months and providing an opcode cache right off the bat would be much preferable to the vast majority of users. People are barely using 5.4 today - it would hardly make a difference if we release 5.5 two months earlier or two months later. But that too would be up for discussion and voting. Zeev --- ## #65389 — Rasmus Lerdorf — 2013-01-29T13:52:41+00:00 URL: https://externals.io/message/65321#65389 · In reply to: #65379 > 2) Isn't APC the standard? Is it in such bad shape it is not even being > considered any longer? As it currently stands from a developer participation standpoint it is not viable. I outlined the issues in a previous post. You also have to take into account that most sites can't actually move to the next release of PHP until APC is stable with it. So effectively the PHP 5.4 release didn't happen until APC 3.1.13 in September 2012 which was a full 6 months after PHP 5.4.0. I don't foresee this getting any better for PHP 5.5. In order for PHP releases to actually mean something this is a problem we have to fix. I honestly don't care which opcode cache implementation we base a core version on, what I care about is developer buy-in. Dmitry and Stas being familiar with the code already outnumbers the number of active core devs working on APC today. I understand some of the skepticism and hurt feelings around this from a few old-timers, but let's move on and see if we can finally push out a release with solid opcode caching right at the release date. From my perspective anything up to a 6-month delay would beat the current situation. -Rasmus --- Next page: https://externals.io/message/65321.md?page=2