[PHP-DEV] Re: [PECL-DEV] [Proposal] New Extension Yac (a user data cache base on shared memory without locks)
On 23/03/13 06:29, Laruence wrote: since Zend O+ has bundled into PHP since 5.5, and O+ is really a bit faster than APC, so people may want to migrate to O+, but there is no User Data Cache in O+ ... Laurence, you are correct that O+ doesn't provide data caching, but what about memcached and the PECL packages that support it? http://pecl.php.net/package/memcache and http://pecl.php.net/package/memcached Regards Terry
Re: [PHP-DEV] Re: [PECL-DEV] [Proposal] New Extension Yac (a user data cache base on shared memory without locks)
Memcached is distributed caching system, where as APC's user data cache is not. Memcached requires separate server instance (memcached) to operate. APC does not. Also, APC's user cache is 5+ times faster than memcached. If some extension is to provide this functionality, it has to be as close as possible in possibilities and speed as APC's implementation has. Memcached is not and never hasn't been an alternative for APC, they are meant for two different jobs. 2013/3/23 Terry Ellison te...@ellisons.org.uk: On 23/03/13 06:29, Laruence wrote: since Zend O+ has bundled into PHP since 5.5, and O+ is really a bit faster than APC, so people may want to migrate to O+, but there is no User Data Cache in O+ ... Laurence, you are correct that O+ doesn't provide data caching, but what about memcached and the PECL packages that support it? http://pecl.php.net/package/memcache and http://pecl.php.net/package/memcached Regards Terry -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP5.5 beta 1 is ready - Fedora RPM
Le 21/03/2013 14:10, Julien Pauli a écrit : Hi Internals, PHP 5.5.0 Beta 1 has been released for testing. A few months ago, PHP 5.5 have been approved as a Fedora 19 feature [1] Despite the delay due to Zend OPcache merge, I still think (and hope) PHP and Fedora roadmap [2][3] are still compatible. I just finish the mass rebuild of PHP and most extensions, so PHP 5.5.0beta1 is already part of Fedora 19. To allow more people to test this new great version, I also build backport RPM for Fedora 17, 18, Enterprise Linux 5 and 6 (RHEL, CentOS, ...) [4] Don't know if a 5.5.0 finale will be available for Fedora 19 release (end of June), but I really hope it will be possible, or at least some Release Candidate. Best regards, Remi. [1] https://fedoraproject.org/wiki/Features/Php55 [2] https://wiki.php.net/todo/php55 (** This one really need update **) [3] https://fedoraproject.org/wiki/Releases/19/Schedule [4] http://blog.famillecollet.com/post/2013/03/21/PHP-5.5.0-in-preparation -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PECL-DEV] [Proposal] New Extension Yac (a user data cache base on shared memory without locks)
On 23/03/13 09:46, Matīss Roberts Treinis wrote: Memcached is distributed caching system, where as APC's user data cache is not. Memcached requires separate server instance (memcached) to operate. APC does not. Yes, but there is nothing to stop an admin of an application-dedicated system or VM configuring and using an in-server memcached. Also, APC's user cache is 5+ times faster than memcached. If some extension is to provide this functionality, it has to be as close as possible in possibilities and speed as APC's implementation has. Memcached is not and never hasn't been an alternative for APC, they are meant for two different jobs. I also agree that memcache is slower because it is out of process and that for some usecases the relative speed differences due to these context switches will impact application performance. Yes, they have different sweet-spots and operational characteristics, but for many usecases the relative impact will be immaterial, and memcached can be a perfectly acceptable substitute. Applications which are closely coupled to high APC data cache usage will probably stay with APC for the foreseeable future. An SMA-based data cache would be a useful adjunct to O+, so I will be interested in this, but I just don't see this filling a show-stopper gap that must be addressed as a priority. snip Laurence, you are correct that O+ doesn't provide data caching, but what about memcached and the PECL packages that support it? http://pecl.php.net/package/memcache and http://pecl.php.net/package/memcached
Re: [PHP-DEV] Re: [PECL-DEV] [Proposal] New Extension Yac (a user data cache base on shared memory without locks)
On Sat, Mar 23, 2013 at 6:31 PM, Terry Ellison te...@ellisons.org.uk wrote: On 23/03/13 09:46, Matīss Roberts Treinis wrote: Memcached is distributed caching system, where as APC's user data cache is not. Memcached requires separate server instance (memcached) to operate. APC does not. Yes, but there is nothing to stop an admin of an application-dedicated system or VM configuring and using an in-server memcached. Also, APC's user cache is 5+ times faster than memcached. If some extension is to provide this functionality, it has to be as close as possible in possibilities and speed as APC's implementation has. Memcached is not and never hasn't been an alternative for APC, they are meant for two different jobs. I also agree that memcache is slower because it is out of process and that for some usecases the relative speed differences due to these context switches will impact application performance. Yes, they have different sweet-spots and operational characteristics, but for many usecases the relative impact will be immaterial, and memcached can be a perfectly acceptable substitute. Applications which are closely coupled to high APC data cache usage will probably stay with APC for the foreseeable future. Hey: APC is not a pure user data cache, the user data cache of it is a additional function of opcodes cache, that means the implemention is restricted by opcodes cache context. and to be honest, I think user data cache and opcodes cache should be separated into different modules.. Yac is a pure user data cache, doesn't have the restriction which APC has, that is why Yac can be implemented without locks. you can see a big performance improvement compare Yac against APC, http://www.laruence.com/2013/03/18/2846.html (use google translate, if you can not read chinese :)) thanks An SMA-based data cache would be a useful adjunct to O+, so I will be interested in this, but I just don't see this filling a show-stopper gap that must be addressed as a priority. snip Laurence, you are correct that O+ doesn't provide data caching, but what about memcached and the PECL packages that support it? http://pecl.php.net/package/memcache and http://pecl.php.net/package/memcached -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PECL-DEV] [Proposal] New Extension Yac (a user data cache base on shared memory without locks)
Le 23/03/2013 12:00, Laruence a écrit : and to be honest, I think user data cache and opcodes cache should be separated into different modules.. Big +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [Proposal] New Extension Yac (a user data cache base on shared memory without locks)
On 03/23/2013 12:07 PM, Remi Collet wrote: Le 23/03/2013 12:00, Laruence a écrit : and to be honest, I think user data cache and opcodes cache should be separated into different modules.. Big +1 And a second big +1 which sums up to almost 3.14 :-) Regards, Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PECL-DEV] [Proposal] New Extension Yac (a user data cache base on shared memory without locks)
On Sat, Mar 23, 2013 at 7:00 AM, Laruence larue...@php.net wrote: On Sat, Mar 23, 2013 at 6:31 PM, Terry Ellison te...@ellisons.org.uk wrote: On 23/03/13 09:46, Matīss Roberts Treinis wrote: Memcached is distributed caching system, where as APC's user data cache is not. Memcached requires separate server instance (memcached) to operate. APC does not. Yes, but there is nothing to stop an admin of an application-dedicated system or VM configuring and using an in-server memcached. Also, APC's user cache is 5+ times faster than memcached. If some extension is to provide this functionality, it has to be as close as possible in possibilities and speed as APC's implementation has. Memcached is not and never hasn't been an alternative for APC, they are meant for two different jobs. I also agree that memcache is slower because it is out of process and that for some usecases the relative speed differences due to these context switches will impact application performance. Yes, they have different sweet-spots and operational characteristics, but for many usecases the relative impact will be immaterial, and memcached can be a perfectly acceptable substitute. Applications which are closely coupled to high APC data cache usage will probably stay with APC for the foreseeable future. Hey: APC is not a pure user data cache, the user data cache of it is a additional function of opcodes cache, that means the implemention is restricted by opcodes cache context. and to be honest, I think user data cache and opcodes cache should be separated into different modules.. Yac is a pure user data cache, doesn't have the restriction which APC has, that is why Yac can be implemented without locks. you can see a big performance improvement compare Yac against APC, http://www.laruence.com/2013/03/18/2846.html (use google translate, if you can not read chinese :)) thanks +1 from me too :) An SMA-based data cache would be a useful adjunct to O+, so I will be interested in this, but I just don't see this filling a show-stopper gap that must be addressed as a priority. snip Laurence, you are correct that O+ doesn't provide data caching, but what about memcached and the PECL packages that support it? http://pecl.php.net/package/memcache and http://pecl.php.net/package/memcached -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PECL-DEV] [Proposal] New Extension Yac (a user data cache base on shared memory without locks)
This looks great, I'm taking a look and testing it!
Re: [PHP-DEV] PHP5.5 beta 1 is ready - Fedora RPM
On 23 March 2013 11:14, Remi Collet r...@fedoraproject.org wrote: Le 21/03/2013 14:10, Julien Pauli a écrit : Hi Internals, PHP 5.5.0 Beta 1 has been released for testing. A few months ago, PHP 5.5 have been approved as a Fedora 19 feature [1] Despite the delay due to Zend OPcache merge, I still think (and hope) PHP and Fedora roadmap [2][3] are still compatible. I just finish the mass rebuild of PHP and most extensions, so PHP 5.5.0beta1 is already part of Fedora 19. To allow more people to test this new great version, I also build backport RPM for Fedora 17, 18, Enterprise Linux 5 and 6 (RHEL, CentOS, ...) [4] Don't know if a 5.5.0 finale will be available for Fedora 19 release (end of June), but I really hope it will be possible, or at least some Release Candidate. Awesome work Remi! Thank you. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP5.5 beta 1 is ready
On Fri, Mar 22, 2013 at 10:04 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! just FYI, there's some non-portable code in Zend OpCache (alpha5 was built just fine), which prevents building of php5 beta1 on non-Linux systems: FreeBSD: https://bugs.php.net/bug.php?id=64490 Hurd i386: https://buildd.debian.org/status/fetch.php?pkg=php5arch=hurd-i386ver=5.5.0~beta1-1stamp=1363956014 While hurd might be not important, the general experience is that writing portable code helps the general quality of the code :). We probably need to make it self-disable on systems where we don't have suitable flock driver. It seems that GNU Hurd does implement flock(). I'll talk to Debian porter team if they can help with the issue there. For freebsd though it's strange since it has if defined(__FreeBSD__) clause there. Is there some other define that should be checked instead? The attached patch to 64490 is correct GNU kFreeBSD defines __FreeBSD_kernel__, there's more info in here: http://glibc-bsd.alioth.debian.org/porting/PORTING O. -- Ondřej Surý ond...@sury.org
Re: [PHP-DEV] PHP5.5 beta 1 is ready
On Thu, 21 Mar 2013, Julien Pauli wrote: Please test the release carefully and report any bugs. Don't forget to activate Zend OPCache and test your code against it. Report any bug you could find. I'm having issues with installing PEAR: Saving to: ‘pear/install-pear-nozlib.phar’ 100%[==] 3,692,810 6.27MB/s in 0.6s 2013-03-23 15:51:04 (6.27 MB/s) - ‘pear/install-pear-nozlib.phar’ saved [3692810/3692810] [PEAR] Archive_Tar: could not extract the package.xml file from phar://install-pear-nozlib.phar/Archive_Tar-1.3.7.tar [PEAR] Console_Getopt: could not extract the package.xml file from phar://install-pear-nozlib.phar/Console_Getopt-1.3.0.tar [PEAR] Structures_Graph: could not extract the package.xml file from phar://install-pear-nozlib.phar/Structures_Graph-1.0.4.tar [PEAR] XML_Util: could not extract the package.xml file from phar://install-pear-nozlib.phar/XML_Util-1.2.1.tar [PEAR] PEAR: could not extract the package.xml file from phar://install-pear-nozlib.phar/PEAR-1.9.4.tar And hence, I have no pecl or pear binaries installed. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP5.5 beta 1 is ready
On Sat, Mar 23, 2013 at 4:53 PM, Derick Rethans der...@php.net wrote: On Thu, 21 Mar 2013, Julien Pauli wrote: Please test the release carefully and report any bugs. Don't forget to activate Zend OPCache and test your code against it. Report any bug you could find. I'm having issues with installing PEAR: Saving to: ‘pear/install-pear-nozlib.phar’ 100%[==] 3,692,810 6.27MB/s in 0.6s 2013-03-23 15:51:04 (6.27 MB/s) - ‘pear/install-pear-nozlib.phar’ saved [3692810/3692810] [PEAR] Archive_Tar: could not extract the package.xml file from phar://install-pear-nozlib.phar/Archive_Tar-1.3.7.tar [PEAR] Console_Getopt: could not extract the package.xml file from phar://install-pear-nozlib.phar/Console_Getopt-1.3.0.tar [PEAR] Structures_Graph: could not extract the package.xml file from phar://install-pear-nozlib.phar/Structures_Graph-1.0.4.tar [PEAR] XML_Util: could not extract the package.xml file from phar://install-pear-nozlib.phar/XML_Util-1.2.1.tar [PEAR] PEAR: could not extract the package.xml file from phar://install-pear-nozlib.phar/PEAR-1.9.4.tar And hence, I have no pecl or pear binaries installed. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php http://www.mail-archive.com/internals@lists.php.net/msg62946.html -- Ferenc Kovács @Tyr43l - http://tyrael.hu
[PHP-DEV] Re: PHP5.5 beta 1 is ready
Le 21/03/2013 06:10, Julien Pauli a écrit : Hi Internals, PHP 5.5.0 Beta 1 has been released for testing. As you know, this code base is shipped with Zend OPCache. The packages can be found at: http://downloads.php.net/dsp and windows packages at http://windows.php.net/qa Please test the release carefully and report any bugs. Don't forget to activate Zend OPCache and test your code against it. Report any bug you could find. Hi, Is there some kind of organized testing programme to test all the popular frameworks, CMSes and libraries? Like, if in addition to testing my own applications, I test the php applications provided by 3rd parties that I also use such as phpbb, dotclear, moonmoon, simplepie... Should I fill in some compability list somewhere stating that is works or doesn't work with beta1 ? And if there are bugs with those applications and the newer version of php, is there a process to follow to flag these issues and take action? Thanks Pascal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Continuous Integration Atomic Deploys and PHP 5.5
One of the things I have been helping companies with for the past couple of years is sorting through the complexities of deploying PHP code with the least possible interruption to the running site. With APC you can achieve atomic deploys without a server restart and without clearing the opcode cache through careful use of the realpath/stat cache and a clearstatcache() call in the front-controller. The logic behind it is a little complicated, but it goes something like this: - Request 1 starts before the deploy and loads script A, B - Deploy to a separate directory and the docroot symlink now points to here - Request 2 starts and loads A, B, C - Request 1 was a bit slow and gets to load C now So this is the scenario that trips up most deploy systems because request 1 would load a version of C that doesn't match A and B already loaded and thus this deploy is not atomic even though all the files were deployed atomically. With the realpath/stat cache and APC's use of inodes as cache keys request 1 will get the inode from the previous version of C, so it will not be out of sync with the previously loaded A and B. In request 2 we put a clearstatcache() call in the front-controller triggered usually by comparing the version baked into the front-controller with a version number written to shared memory. So by detecting that there is a more recent version of the code available in the front-controller at the start of a request we can make sure that all new requests will see the new code while requests that were executing when the deploy happened will continue to use the previous version until they are done. Now, with PHP 5.5 and the new OPcache things are a bit different. OPcache is not inode-based so we can't use the same trick. Since we are focusing on a single cache implementation I think we should document a preferred approach to this common scenario. I see a couple of approaches: 1. Turn off validate_timestamps and always do a graceful server restart on a deploy + effective - slow and annoying when you deploy a lot, especially companies who do a lot of A/B testing and feature-based development with potentially hundreds of small code and config deploys to ramp features up/down throughout the day. Being able to invalidate a single cache entry might mean you could avoid doing the full restart on a simple config-file deploy, but currently opcache can't do that(*) 2. Do something interesting with revalidate_freq. If we always knew that the file stat happened at :00 of the minute and we deploy at :01 then perhaps we could get away with not doing anything else + no server restarts and no cache clears - scripts that take longer than 59 seconds to complete would be a problem and the code currently can't guarantee timestamps checks at regular intervals like this 3. Add some magic to OPcache that gives it the concept of a server request. Almost like a DB transaction. Currently on a cache reset, OPcache lets currently executing entries complete, but this is on a per-entry basis. A web request is made up of many of these entries so unless they are somehow bracketed it doesn't help us. So something like opcache_request_begin()/opcache_request_done() might work. + no server restarts and no cache clears - This might get way too complex, especially since userspace may never call opcache_request_done() which means we would need some sort of timeout mechanism as well (*) for single-file deploys, such as a config-change to ramp a feature up or down you could blacklist the config file and use apcu/yac or some other user cache mechanism to speed things up. None of these approaches sound ideal to me, and that includes the existing inode-caching APC approach. Too brittle and complicated. Any other ideas? -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP5.5 beta 1 is ready
hi! On Sat, Mar 23, 2013 at 5:46 PM, Pascal Chevrel pascal.chev...@free.fr wrote: Is there some kind of organized testing programme to test all the popular frameworks, CMSes and libraries? Like, if in addition to testing my own applications, I test the php applications provided by 3rd parties that I also use such as phpbb, dotclear, moonmoon, simplepie... Should I fill in some compability list somewhere stating that is works or doesn't work with beta1 ? That would be awesome, our team does that too, with major apps and frameworks. Almost all reports get uploaded f.e. here (and higher dirs), for one revision: http://windows.php.net/downloads/snaps/ostc/pftt/PHP_5_5/r0d65a85/ cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Continuous Integration Atomic Deploys and PHP 5.5
On Sat, Mar 23, 2013 at 7:57 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: One of the things I have been helping companies with for the past couple of years is sorting through the complexities of deploying PHP code with the least possible interruption to the running site. With APC you can achieve atomic deploys without a server restart and without clearing the opcode cache through careful use of the realpath/stat cache and a clearstatcache() call in the front-controller. The logic behind it is a little complicated, but it goes something like this: - Request 1 starts before the deploy and loads script A, B - Deploy to a separate directory and the docroot symlink now points to here - Request 2 starts and loads A, B, C - Request 1 was a bit slow and gets to load C now So this is the scenario that trips up most deploy systems because request 1 would load a version of C that doesn't match A and B already loaded and thus this deploy is not atomic even though all the files were deployed atomically. With the realpath/stat cache and APC's use of inodes as cache keys request 1 will get the inode from the previous version of C, so it will not be out of sync with the previously loaded A and B. In request 2 we put a clearstatcache() call in the front-controller triggered usually by comparing the version baked into the front-controller with a version number written to shared memory. So by detecting that there is a more recent version of the code available in the front-controller at the start of a request we can make sure that all new requests will see the new code while requests that were executing when the deploy happened will continue to use the previous version until they are done. Now, with PHP 5.5 and the new OPcache things are a bit different. OPcache is not inode-based so we can't use the same trick. Since we are focusing on a single cache implementation I think we should document a preferred approach to this common scenario. I see a couple of approaches: 1. Turn off validate_timestamps and always do a graceful server restart on a deploy + effective - slow and annoying when you deploy a lot, especially companies who do a lot of A/B testing and feature-based development with potentially hundreds of small code and config deploys to ramp features up/down throughout the day. Being able to invalidate a single cache entry might mean you could avoid doing the full restart on a simple config-file deploy, but currently opcache can't do that(*) 2. Do something interesting with revalidate_freq. If we always knew that the file stat happened at :00 of the minute and we deploy at :01 then perhaps we could get away with not doing anything else + no server restarts and no cache clears - scripts that take longer than 59 seconds to complete would be a problem and the code currently can't guarantee timestamps checks at regular intervals like this 3. Add some magic to OPcache that gives it the concept of a server request. Almost like a DB transaction. Currently on a cache reset, OPcache lets currently executing entries complete, but this is on a per-entry basis. A web request is made up of many of these entries so unless they are somehow bracketed it doesn't help us. So something like opcache_request_begin()/opcache_request_done() might work. + no server restarts and no cache clears - This might get way too complex, especially since userspace may never call opcache_request_done() which means we would need some sort of timeout mechanism as well (*) for single-file deploys, such as a config-change to ramp a feature up or down you could blacklist the config file and use apcu/yac or some other user cache mechanism to speed things up. None of these approaches sound ideal to me, and that includes the existing inode-caching APC approach. Too brittle and complicated. Any other ideas? -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php realpath the document root(which is a symlink to the actual release directory) from your index.php/bootstrap file and use that as a base path for making absolute paths everywhere? that way the requests started before the symlink switch will continue with the old version but requests started after the switch will use the files from the new revision. ofc. you can still have issues like an ajax request from the old version gets served by the new version, and if you have more than one server sooner or later you will/have to sacrifice something from the CAP trio. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Continuous Integration Atomic Deploys and PHP 5.5
On 03/23/2013 03:01 PM, Ferenc Kovacs wrote: realpath the document root(which is a symlink to the actual release directory) from your index.php/bootstrap file and use that as a base path for making absolute paths everywhere? that way the requests started before the symlink switch will continue with the old version but requests started after the switch will use the files from the new revision. ofc. you can still have issues like an ajax request from the old version gets served by the new version, and if you have more than one server sooner or later you will/have to sacrifice something from the CAP trio. Well, solving the multi-request/multi-server ajax scenario is a bit of a different problem. You'd need to version those requests to handle that. The scope I am concerned with here is per-server deploy atomicity. But yes, some way to have a 2-docroot scenario where all requests started on one via the docroot symlink stays on that one would be a good approach but it would take a lot of discipline at the userspace level to enforce that across a large and diverse codebase with autoloaders and actual realpath calls all over the place. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] OPcache precompiled dll's for older Windows versions
Would it be an idea to put several flavours of php_opcache.dll at http://windows.php.net/downloads/pecl/snaps/ These are quite 'old': http://windows.php.net/downloads/pecl/snaps/ZendOptimizerPlus/7.0.1-dev/ See the requests for such dll's at http://www.apachelounge.com/viewtopic.php?t=5242#24199 Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP5.5 beta 1 is ready
Pierre Joye in php.internals (Sat, 23 Mar 2013 20:31:38 +0100): That would be awesome, our team does that too, with major apps and frameworks. Almost all reports get uploaded f.e. here (and higher dirs), for one revision: http://windows.php.net/downloads/snaps/ostc/pftt/PHP_5_5/r0d65a85/ How should I read http://windows.php.net/downloads/snaps/ostc/pftt/perf/results-20130321-5.5.0beta1-5.5r293d5de.html Is that with OPcache? Previously you were using Wincache and APC as well, but things seems to have changed around this report: http://windows.php.net/downloads/snaps/ostc/pftt/perf/results-20130222-5.4.11-5.5.0alpha5vc9.html Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP5.5 beta 1 is ready
On Sat, Mar 23, 2013 at 5:02 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Sat, Mar 23, 2013 at 4:53 PM, Derick Rethans der...@php.net wrote: On Thu, 21 Mar 2013, Julien Pauli wrote: Please test the release carefully and report any bugs. Don't forget to activate Zend OPCache and test your code against it. Report any bug you could find. I'm having issues with installing PEAR: Saving to: ‘pear/install-pear-nozlib.phar’ 100%[==] 3,692,810 6.27MB/s in 0.6s 2013-03-23 15:51:04 (6.27 MB/s) - ‘pear/install-pear-nozlib.phar’ saved [3692810/3692810] [PEAR] Archive_Tar: could not extract the package.xml file from phar://install-pear-nozlib.phar/Archive_Tar-1.3.7.tar [PEAR] Console_Getopt: could not extract the package.xml file from phar://install-pear-nozlib.phar/Console_Getopt-1.3.0.tar [PEAR] Structures_Graph: could not extract the package.xml file from phar://install-pear-nozlib.phar/Structures_Graph-1.0.4.tar [PEAR] XML_Util: could not extract the package.xml file from phar://install-pear-nozlib.phar/XML_Util-1.2.1.tar [PEAR] PEAR: could not extract the package.xml file from phar://install-pear-nozlib.phar/PEAR-1.9.4.tar And hence, I have no pecl or pear binaries installed. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php http://www.mail-archive.com/internals@lists.php.net/msg62946.html -- Ferenc Kovács @Tyr43l - http://tyrael.hu I think I've fixed the problem and sent a PR to the PEAR guys ( https://github.com/pear/pear-core/pull/12 btw. there were already a PR for this: https://github.com/pear/pear-core/pull/10 I just didn't noticed until I've sent mine), hopefully they merge it soon, if not we can still build our self and upload it somewhere and change the pear/Makefile.frag to wget that version. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] PHP5.5 beta 1 is ready
On Sun, Mar 24, 2013 at 3:06 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Sat, Mar 23, 2013 at 5:02 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Sat, Mar 23, 2013 at 4:53 PM, Derick Rethans der...@php.net wrote: On Thu, 21 Mar 2013, Julien Pauli wrote: Please test the release carefully and report any bugs. Don't forget to activate Zend OPCache and test your code against it. Report any bug you could find. I'm having issues with installing PEAR: Saving to: ‘pear/install-pear-nozlib.phar’ 100%[==] 3,692,810 6.27MB/s in 0.6s 2013-03-23 15:51:04 (6.27 MB/s) - ‘pear/install-pear-nozlib.phar’ saved [3692810/3692810] [PEAR] Archive_Tar: could not extract the package.xml file from phar://install-pear-nozlib.phar/Archive_Tar-1.3.7.tar [PEAR] Console_Getopt: could not extract the package.xml file from phar://install-pear-nozlib.phar/Console_Getopt-1.3.0.tar [PEAR] Structures_Graph: could not extract the package.xml file from phar://install-pear-nozlib.phar/Structures_Graph-1.0.4.tar [PEAR] XML_Util: could not extract the package.xml file from phar://install-pear-nozlib.phar/XML_Util-1.2.1.tar [PEAR] PEAR: could not extract the package.xml file from phar://install-pear-nozlib.phar/PEAR-1.9.4.tar And hence, I have no pecl or pear binaries installed. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php http://www.mail-archive.com/internals@lists.php.net/msg62946.html -- Ferenc Kovács @Tyr43l - http://tyrael.hu I think I've fixed the problem and sent a PR to the PEAR guys ( https://github.com/pear/pear-core/pull/12 btw. there were already a PR for this: https://github.com/pear/pear-core/pull/10 I just didn't noticed until I've sent mine), hopefully they merge it soon, if not we can still build our self and upload it somewhere and change the pear/Makefile.frag to wget that version. Sherif also confirmed that the phar file produced by the patched pear script results in a working pear install. We have http://php.net/63073 to track an issue on our part and I also opened a bug on pear.php.net just to be sure that it won't be forgotten this time: https://pear.php.net/bugs/bug.php?id=19867 -- Ferenc Kovács @Tyr43l - http://tyrael.hu
