.. is in devel:languages:php:php55. Feel free to test and tell your opinion about factory inclusion. http://www.php.net/manual/en/migration55.incompatible.php Thanks! Petr
On 02.07.2013 16:27, Petr Gajdos wrote:
.. is in devel:languages:php:php55. Feel free to test and tell your opinion about factory inclusion.
Ha, you were faster than me. I think we should decide carefully. PHP 5.5 comes with a new opcode cache while APC always used to lag behind PHP releases. But AFAIK the Zend Opcode extension has no userland cache yet. That might break large installations. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Ralf, On Tue, Jul 02, 2013 at 07:10:17PM +0200, Ralf Lang wrote:
PHP 5.5 comes with a new opcode cache while APC always used to lag behind PHP releases. But AFAIK the Zend Opcode extension has no userland cache yet. That might break large installations.
very many thanks for warning. Do we have any way how to test it? Petr
On 02.07.2013 19:21, Petr Gajdos wrote:
Ralf,
On Tue, Jul 02, 2013 at 07:10:17PM +0200, Ralf Lang wrote:
PHP 5.5 comes with a new opcode cache while APC always used to lag behind PHP releases. But AFAIK the Zend Opcode extension has no userland cache yet. That might break large installations.
very many thanks for warning. Do we have any way how to test it?
There's nothing we can do about people upgrading to opensuse-next. I'll dig through the php-internals list if I find something on this topic. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
Hello, Am Dienstag, 2. Juli 2013 schrieb Ralf Lang:
I think we should decide carefully. PHP 5.5 comes with a new opcode cache while APC always used to lag behind PHP releases. But AFAIK the Zend Opcode extension has no userland cache yet. That might break large installations.
Not only large installations - the userland cache is also very useful on quite small setups, even on bored servers ;-) My experience is (with 12.3 on a new rootserver): I moved a mediawiki (about 800 MB traffic per day) on the server. This resulted in a load of 0.2 (aka "bored"). Then I installed php5-APC and configured mediawiki to use it as cache. This reduced the load to 0.1 and, much more important, resulted in a big improvement in page load times. I don't have exact numbers, but the difference was between "it's ok" and "wow!" ;-) In other words: the userland cache is worth *a lot* - my customer would for sure complain if I disable it ;-) (Yes, mediawiki makes heavy use of the cache - your milage may vary for other software.) Regards, Christian Boltz -- well that's my 2c worth. Well about 1.7 cents with the current exchange rate. [Helen South in opensuse-project] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 02/07/13 18:22, Christian Boltz escribió:
In other words: the userland cache is worth *a lot* - my customer would for sure complain if I disable it ;-)
There seems to be a confusion in your interpretation about userland cache.. "userland cache" refers to functionality implemented by PHP extensions which allows the user to store arbitrary data in a shared memory backed cache. This is not the same thing as the opcode cache, which only stores the bytecode of PHP scripts. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 03.07.2013 00:33, Cristian Rodríguez wrote:
El 02/07/13 18:22, Christian Boltz escribió:
In other words: the userland cache is worth *a lot* - my customer would for sure complain if I disable it ;-)
There seems to be a confusion in your interpretation about userland cache.. "userland cache" refers to functionality implemented by PHP extensions which allows the user to store arbitrary data in a shared memory backed cache. This is not the same thing as the opcode cache, which only stores the bytecode of PHP scripts.
Yes. php 5.5 comes with a bytecode cache extension (the opensourced version of Zend Optimizer+). APC had a similar bytecode cache (which applies to any php script automagically when loaded) and a userland cache (key/value store for user data; only for apps that are aware of APC and use special functions). A new extension APCu seems to provide userland cache and wraps the new bytecode cache into the old APC api. http://pecl.php.net/package-changelog.php?package=APCu&release=4.0.0 http://blog.famillecollet.com/post/2013/03/27/php-pecl-apcu-4.0.0-en http://blog.famillecollet.com/post/2013/03/25/PHP-opcode-and-user-data-cache There was a recent thread in may on php-internals: (clippings) "PHP 5.5 and APC user cache upgrade path". "> * Is APC basically dead and wont support PHP 5.5? From the lack of APC activity and from comments Rasmus has made in the bugs (e.g. [1]) this is a safe assumption." "By default, APCu builds in an APC-compatible manner, emulating the old functions for APC, no change should be required to run legacy code relying on APC. New features, if they are written, will not be included in the APCu codebase, instead, APCu exposes all of it's API to other extensions, which allows any future features to be written and maintained completely separately, which I think to be a better solution as APC is in such heavy use. Very few people are able to helpfully maintain an opcode cache, the idea of including opcache in the core, or one of the ideas/benefits, is that everyone able can concentrate on one solution, implicitly APC will fall by the wayside where opcode caching is concerned. However, it is possible to run APC and opcache side by side by fiddling with ini settings, I can't really say if this is advisable or not, a possibility all the same. " So I think, we need to ship php5-APCu when we upgrade php core to 5.5.0 in factory and DR php5-APC Somebody already stepped forward: https://build.opensuse.org/package/show/home:munix9:php/php5-apcu -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
On 07/03/2013 02:10 AM, Ralf Lang wrote:
Yes. php 5.5 comes with a bytecode cache extension (the opensourced version of Zend Optimizer+).
I have not been involved in php internals development for a long while but I can safely assume that the politics surrounding this change must have been as delightful as a brick through the window :-D In the end it probably boils down to someone commiting re$$ources to develop and maintain that thing..
Very few people are able to helpfully maintain an opcode cache,
less than 5 in the face of planet earth more precisely.
So I think, we need to ship php5-APCu when we upgrade php core to 5.5.0 in factory and DR php5-APC
Yeah, I will inevitably have to take a look at this too,..have code running with both the bytecode and user cache and do not feel like hacking around that codebase [1] so I better spend some time trying to make the switch as painless as possible..here we go again.. :-) [1] likely reaction --> http://s209.photobucket.com/user/DJ_Napps/media/omg.gif.html -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 03.07.2013 09:08, Cristian Rodríguez wrote:
On 07/03/2013 02:10 AM, Ralf Lang wrote:
Yes. php 5.5 comes with a bytecode cache extension (the opensourced version of Zend Optimizer+).
I have not been involved in php internals development for a long while but I can safely assume that the politics surrounding this change must have been as delightful as a brick through the window :-D
Hehe, yes, it was a very wordy debate. In the end, Rasmus admitted that APC lacks resources to keep up with PHP and Zeev (Zend) stepped in and offered their bytecode cache + resources, which may or may not move into PHP core later on.
In the end it probably boils down to someone commiting re$$ources to develop and maintain that thing.. Right.
So I think, we need to ship php5-APCu when we upgrade php core to 5.5.0 in factory and DR php5-APC
Yeah, I will inevitably have to take a look at this too,..have code running with both the bytecode and user cache and do not feel like hacking around that codebase [1] so I better spend some time trying to make the switch as painless as possible..here we go again.. :-)
BTW: https://build.opensuse.org/package/show/devel:languages:php:php55/php5 * php5-64-bit-post-large-files.patch I am suggesting to remove php5-64-bit-post-large-files.patch from php55:php5 and replace it with a more upstream-ready version which uses def_t (basically unsigned long long) instead of signed long. I am currently involved with getting this patch upstream in time for php 5.6 SR will follow. https://bugs.php.net/bug.php?id=44522 * php5-suhosin-php55.patch I suggest removing suhosin (patch). The last official upstream release of suhosin was for php 5.3.9, the project seems dead and others have dumped it or have been discussing the same move. I believe that we have bright patchers who keep this upstream patch alive, but is it worth it? There is also a suhosin extension which seems to work independently of the patch. https://pierre-schmitz.com/php-5-4-1-in-suhosin-out/ https://bugs.launchpad.net/ubuntu/+source/php-suhosin/+bug/1086984 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657698 I know this latter part is potentially a hard debate. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
On Wed, Jul 03, 2013 at 09:58:09AM +0200, Ralf Lang wrote:
BTW: https://build.opensuse.org/package/show/devel:languages:php:php55/php5
* php5-64-bit-post-large-files.patch
I am suggesting to remove php5-64-bit-post-large-files.patch from php55:php5 and replace it with a more upstream-ready version which uses def_t (basically unsigned long long) instead of signed long. I am currently involved with getting this patch upstream in time for php 5.6
SR will follow.
Will accept.
* php5-suhosin-php55.patch
I suggest removing suhosin (patch). The last official upstream release of suhosin was for php 5.3.9, the project seems dead and others have dumped it or have been discussing the same move.
I believe that we have bright patchers who keep this upstream patch alive, but is it worth it?
There is also a suhosin extension which seems to work independently of the patch.
php5-suhosin-php55.patch patches this extension :-). I have removed suhosin patch by php 5.4. Petr
On 03.07.2013 10:09, pgajdos@suse.cz wrote:
On Wed, Jul 03, 2013 at 09:58:09AM +0200, Ralf Lang wrote:
BTW: https://build.opensuse.org/package/show/devel:languages:php:php55/php5
* php5-64-bit-post-large-files.patch
I am suggesting to remove php5-64-bit-post-large-files.patch from php55:php5 and replace it with a more upstream-ready version which uses def_t (basically unsigned long long) instead of signed long. I am currently involved with getting this patch upstream in time for php 5.6
SR will follow.
Will accept.
request id 181833
There is also a suhosin extension which seems to work independently of the patch.
php5-suhosin-php55.patch patches this extension :-). I have removed suhosin patch by php 5.4.
oops. ;) Quilt somehow could not apply it to the correct files but rpm still builds it. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
On Wed, Jul 03, 2013 at 10:43:44AM +0200, Ralf Lang wrote:
Will accept.
request id 181833
Accepted, thanks!
There is also a suhosin extension which seems to work independently of the patch.
php5-suhosin-php55.patch patches this extension :-). I have removed suhosin patch by php 5.4.
oops. ;)
Quilt somehow could not apply it to the correct files but rpm still builds it.
%prep is not quilt friendly. $ cat ~/bin/qphp rm -rf php-*/ qsetup pushd php-*/ mv suhosin-* ext/suhosin qpush Petr
On 07/03/2013 03:58 AM, Ralf Lang wrote:
I am suggesting to remove php5-64-bit-post-large-files.patch from php55:php5 and replace it with a more upstream-ready version which uses def_t (basically unsigned long long) instead of signed long. I am currently involved with getting this patch upstream in time for php 5.6
brave soul! :-) last time I checked there were quite a bit of code that assumed and expected 32 bit signed integers..and wasn't easy to get around that.
I suggest removing suhosin (patch).
Yes, if it is no longer under development then it must go for good. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (5)
-
Christian Boltz -
Cristian Rodríguez -
Petr Gajdos -
pgajdos＠suse.cz
-
Ralf Lang