Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?
hi! On Wed, Oct 24, 2012 at 10:47 PM, Eric Stenson erics...@microsoft.com wrote: From: Anthony Ferrara [mailto:ircmax...@gmail.com] [Pierre said:] It is still the case. I for one would like to kill all the legacy features or too specific features which are really unusable by any common developers. Other developers may disagree but it makes very hard to maintain APC. Perhaps that indicates it's time to pull the core of APC into php's core... Just the core, not all of those other features. Then the APC extension can still exist for those additional legacy features, but the core functionality can be shipped with PHP itself. I know there was talk about adding that to php6 by default, perhaps 5.5 (or 5.6) could benefit from it... Sorry for reviving a long-dead thread: I absolutely concur that the core of APC should get pulled into subsequent versions of PHP...then Wincache can go away. ;) Any help would be appreciated. What is very in wincache is that many APC options are default in wincache. The filecache could be extracted as well and made a standalone ext (that's easier to maintain and need separate cache :). That's something we discuss back then when the 1st versions of wincache were being implemented. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?
From: Anthony Ferrara [mailto:ircmax...@gmail.com] [Pierre said:] It is still the case. I for one would like to kill all the legacy features or too specific features which are really unusable by any common developers. Other developers may disagree but it makes very hard to maintain APC. Perhaps that indicates it's time to pull the core of APC into php's core... Just the core, not all of those other features. Then the APC extension can still exist for those additional legacy features, but the core functionality can be shipped with PHP itself. I know there was talk about adding that to php6 by default, perhaps 5.5 (or 5.6) could benefit from it... Sorry for reviving a long-dead thread: I absolutely concur that the core of APC should get pulled into subsequent versions of PHP...then Wincache can go away. ;) Thx! --E. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?
hi Tom, On Wed, Jul 4, 2012 at 4:37 PM, Tom Boutell t...@punkave.com wrote: Hmm, but the stat=0 optimization is a major one; a cache that didn't offer it would be significantly slower in production for those who know what they're doing, yes? yes and no, really depends on the codes. However my point was not really about the importance of a given feature but its limitation or drawbacks. stat=0 being the one causing most troubles to lambda users (relative paths usage and the likes). That could be done in a more transparent way, without needing an option to enable this optimization (wincache and other does it). So could be other options, limit them to the critical ones (size of the cache and the likes) and leave the rest to our choices, filling the mass needs before the needs of the 1%. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?
hi Rasmus, On Tue, Jul 3, 2012 at 6:35 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 07/03/2012 08:17 AM, Pierre Joye wrote: I for one would like to kill all the legacy features or too specific features which are really unusable by any common developers. Other developers may disagree but it makes very hard to maintain APC. There are really just two big features in APC. The opcode caching and the user-cache that sits on top of the same shared memory segment used by the opcode cache. Right, I wold like to split them tho'. To have two independent memory for opcodes and user cache. Everything else are just little tweaks that amount to very little code. Maintenance complexity is not necessary related to the amount of code but the amount of cases to test. These cases also make very hard for our users to understand APC and how it behaves (the stat=0 being the easiest one to understand but causing most issues, for example). That's where eAccelerator or xCache do way better, if it works, it simply works, no magic option or other confusing (for the users) options. The biggest cleanup we would get moving it to core would be the ability to drop all the #ifdef checks for the different engine versions since we would obviously only need to support the current one. We will still have to support current supported versions via PECL. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?
On 2012-07-03 20:49, Arvids Godjuks wrote: One one side it's good to know i'm not wrong, on the other hand it's sad in this case. Sure about one thing - xcache is worth looking at and may be a better choise than APC and has better potential. One thing sure - I haven't heard anyone complaining about xcache. And heard many complains about APC. XCache just crashed for me: http://xcache.lighttpd.net/ticket/240 No reproduce case and no idea how to make one - there are megabytes of code involved. We've been using APC for a year and a half after that and I was pretty much happy with it, except it crashed ~once a day with totally obscure backtrace. Not much of a problem, but kind of annoying and APC sources gave me headaches, so I revived eAccelerator instead and made it work with 5.3. With EA there was absolutely no difference in performance comparing to APC and the crashes are gone now. But now I'll have to make EA work with 5.4 and it's interned string hell.., which is quite different story. You might want to look at my EA fork, though: https://github.com/tony2001/eaccelerator/tree/alt -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?
Hmm, but the stat=0 optimization is a major one; a cache that didn't offer it would be significantly slower in production for those who know what they're doing, yes? (I haven't actually tried the stat=0 trick myself yet and don't have performance numbers on its impact. I really ought to though, since hitting an API URL that clears the APC cache as part of deployment should be pretty easy.) On Wed, Jul 4, 2012 at 5:55 AM, Pierre Joye pierre@gmail.com wrote: hi Rasmus, On Tue, Jul 3, 2012 at 6:35 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 07/03/2012 08:17 AM, Pierre Joye wrote: I for one would like to kill all the legacy features or too specific features which are really unusable by any common developers. Other developers may disagree but it makes very hard to maintain APC. There are really just two big features in APC. The opcode caching and the user-cache that sits on top of the same shared memory segment used by the opcode cache. Right, I wold like to split them tho'. To have two independent memory for opcodes and user cache. Everything else are just little tweaks that amount to very little code. Maintenance complexity is not necessary related to the amount of code but the amount of cases to test. These cases also make very hard for our users to understand APC and how it behaves (the stat=0 being the easiest one to understand but causing most issues, for example). That's where eAccelerator or xCache do way better, if it works, it simply works, no magic option or other confusing (for the users) options. The biggest cleanup we would get moving it to core would be the ability to drop all the #ifdef checks for the different engine versions since we would obviously only need to support the current one. We will still have to support current supported versions via PECL. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?
On 07/04/2012 07:37 AM, Tom Boutell wrote: Hmm, but the stat=0 optimization is a major one; a cache that didn't offer it would be significantly slower in production for those who know what they're doing, yes? Depends on your code. For people who write code that needs to include hundreds, or even thousands of files per request, yes, stat=0 is a big feature. For saner code it is much less important. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?
Heh... passing a little judgment there on the design of frameworks, ORMs, etc. are we? On Wed, Jul 4, 2012 at 10:41 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 07/04/2012 07:37 AM, Tom Boutell wrote: Hmm, but the stat=0 optimization is a major one; a cache that didn't offer it would be significantly slower in production for those who know what they're doing, yes? Depends on your code. For people who write code that needs to include hundreds, or even thousands of files per request, yes, stat=0 is a big feature. For saner code it is much less important. -Rasmus -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?
This one: *** glibc detected *** /usr/local/bin/php-cgi: double free or corruption (out): 0x7f9d6ce2c080 *** === Backtrace: = /lib/libc.so.6(+0x77806)[0x7f9d679be806] /lib/libc.so.6(cfree+0x73)[0x7f9d679c50d3] /usr/local/bin/php-cgi(destroy_zend_class+0x23d)[0x749f5d] /usr/local/bin/php-cgi(zend_hash_clean+0x73)[0x75f393] /usr/local/lib/php/extensions/no-debug-non-zts-20100525/apc.so(apc_interned_strings_shutdown+0x20)[0x7f9d65d1e460] Is pretty nasty and we're getting it on lots of servers. #61238 says it's a known and fixed issue, but we still have it with a fresh build of PHP 5.4.4 and apc installed immediately thereafter via pecl. Is this fix actually released yet? Thanks. -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?
On 07/03/2012 07:13 AM, Tom Boutell wrote: This one: *** glibc detected *** /usr/local/bin/php-cgi: double free or corruption (out): 0x7f9d6ce2c080 *** === Backtrace: = /lib/libc.so.6(+0x77806)[0x7f9d679be806] /lib/libc.so.6(cfree+0x73)[0x7f9d679c50d3] /usr/local/bin/php-cgi(destroy_zend_class+0x23d)[0x749f5d] /usr/local/bin/php-cgi(zend_hash_clean+0x73)[0x75f393] /usr/local/lib/php/extensions/no-debug-non-zts-20100525/apc.so(apc_interned_strings_shutdown+0x20)[0x7f9d65d1e460] Is pretty nasty and we're getting it on lots of servers. #61238 says it's a known and fixed issue, but we still have it with a fresh build of PHP 5.4.4 and apc installed immediately thereafter via pecl. Is this fix actually released yet? Like I said in the bug report, install APC from SVN. We have a few more things to fix before we are ready for an APC release. Unfortunately there are a lot fewer people working on APC than other parts of PHP. It is extremely difficult and not very sexy work. And with that enticing description, if anyone reading this would like to pitch in and help fix the remaining small PHP 5.4 edge cases in APC, it would be much appreciated. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?
Given the impracticality of using PHP without APC, it would be nice if it were part of the main if these fail, it's not ready test suite. But I suppose that's just administering beatings until morale improves (: On Tue, Jul 3, 2012 at 10:20 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 07/03/2012 07:13 AM, Tom Boutell wrote: This one: *** glibc detected *** /usr/local/bin/php-cgi: double free or corruption (out): 0x7f9d6ce2c080 *** === Backtrace: = /lib/libc.so.6(+0x77806)[0x7f9d679be806] /lib/libc.so.6(cfree+0x73)[0x7f9d679c50d3] /usr/local/bin/php-cgi(destroy_zend_class+0x23d)[0x749f5d] /usr/local/bin/php-cgi(zend_hash_clean+0x73)[0x75f393] /usr/local/lib/php/extensions/no-debug-non-zts-20100525/apc.so(apc_interned_strings_shutdown+0x20)[0x7f9d65d1e460] Is pretty nasty and we're getting it on lots of servers. #61238 says it's a known and fixed issue, but we still have it with a fresh build of PHP 5.4.4 and apc installed immediately thereafter via pecl. Is this fix actually released yet? Like I said in the bug report, install APC from SVN. We have a few more things to fix before we are ready for an APC release. Unfortunately there are a lot fewer people working on APC than other parts of PHP. It is extremely difficult and not very sexy work. And with that enticing description, if anyone reading this would like to pitch in and help fix the remaining small PHP 5.4 edge cases in APC, it would be much appreciated. -Rasmus -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?
hi Tom, On Tue, Jul 3, 2012 at 4:49 PM, Tom Boutell t...@punkave.com wrote: Given the impracticality of using PHP without APC, it would be nice if it were part of the main if these fail, it's not ready test suite. But I suppose that's just administering beatings until morale improves (: That's why latest APC releases are beta and not stable. Interned string and a couple of other things need some more work to get fixed. One way to speed up things is to provide small reproduce cases for bugs, so we can fix them quicker. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?
hi, On Tue, Jul 3, 2012 at 5:12 PM, Arvids Godjuks arvids.godj...@gmail.com wrote: There are alternative opcode cachers besides APC. For example xcache, for me, just works when APC is still catching up. I remember someone writing about APC that it is overly compex internally and due to that hard to keep up with the changes in the PHP, maybe that is not the case now. It is still the case. I for one would like to kill all the legacy features or too specific features which are really unusable by any common developers. Other developers may disagree but it makes very hard to maintain APC. Cheers, 2012/7/3 Tom Boutell t...@punkave.com Given the impracticality of using PHP without APC, it would be nice if it were part of the main if these fail, it's not ready test suite. But I suppose that's just administering beatings until morale improves (: -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?
There are alternative opcode cachers besides APC. For example xcache, for me, just works when APC is still catching up. I remember someone writing about APC that it is overly compex internally and due to that hard to keep up with the changes in the PHP, maybe that is not the case now. But looking at the xcache and using it in production for 5-6 years I see that something is true in the previous statement, because when new version is out - xcache is always up to date, witch can't be said about the APC. Just say'n. 2012/7/3 Tom Boutell t...@punkave.com Given the impracticality of using PHP without APC, it would be nice if it were part of the main if these fail, it's not ready test suite. But I suppose that's just administering beatings until morale improves (:
Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?
Pierre, It is still the case. I for one would like to kill all the legacy features or too specific features which are really unusable by any common developers. Other developers may disagree but it makes very hard to maintain APC. Perhaps that indicates it's time to pull the core of APC into php's core... Just the core, not all of those other features. Then the APC extension can still exist for those additional legacy features, but the core functionality can be shipped with PHP itself. I know there was talk about adding that to php6 by default, perhaps 5.5 (or 5.6) could benefit from it... Thoughts? Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?
It is still the case. I for one would like to kill all the legacy features or too specific features which are really unusable by any common developers. Other developers may disagree but it makes very hard to maintain APC. Perhaps that indicates it's time to pull the core of APC into php's core... Just the core, not all of those other features. Then the APC extension can still exist for those additional legacy features, but the core functionality can be shipped with PHP itself. I know there was talk about adding that to php6 by default, perhaps 5.5 (or 5.6) could benefit from it... Thoughts? Would that provide an sufficent improvement over the alternatives to justify forcing it's general use. I still prefer eaccellerator from a performance point of view ... And others do prefer the alternatives. Almost worth asking which Is prefered.
Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?
The ability to store your own data in the APC cache is a feature that does get used a lot in the Symfony framework world because of the availability of the sfAPCCache and whatever its Symfony 2 equivalent is. It's popular with folks who haven't felt the need to set up Redis or some other external cache yet. I'm not sure whether this is something you consider a legacy feature. On Tue, Jul 3, 2012 at 11:17 AM, Pierre Joye pierre@gmail.com wrote: hi, On Tue, Jul 3, 2012 at 5:12 PM, Arvids Godjuks arvids.godj...@gmail.com wrote: There are alternative opcode cachers besides APC. For example xcache, for me, just works when APC is still catching up. I remember someone writing about APC that it is overly compex internally and due to that hard to keep up with the changes in the PHP, maybe that is not the case now. It is still the case. I for one would like to kill all the legacy features or too specific features which are really unusable by any common developers. Other developers may disagree but it makes very hard to maintain APC. Cheers, 2012/7/3 Tom Boutell t...@punkave.com Given the impracticality of using PHP without APC, it would be nice if it were part of the main if these fail, it's not ready test suite. But I suppose that's just administering beatings until morale improves (: -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?
On 07/03/2012 08:17 AM, Pierre Joye wrote: I for one would like to kill all the legacy features or too specific features which are really unusable by any common developers. Other developers may disagree but it makes very hard to maintain APC. There are really just two big features in APC. The opcode caching and the user-cache that sits on top of the same shared memory segment used by the opcode cache. Everything else are just little tweaks that amount to very little code. The biggest cleanup we would get moving it to core would be the ability to drop all the #ifdef checks for the different engine versions since we would obviously only need to support the current one. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?
One one side it's good to know i'm not wrong, on the other hand it's sad in this case. Sure about one thing - xcache is worth looking at and may be a better choise than APC and has better potential. One thing sure - I haven't heard anyone complaining about xcache. And heard many complains about APC. 03.07.2012 15:17 пользователь Pierre Joye pierre@gmail.com написал: hi, On Tue, Jul 3, 2012 at 5:12 PM, Arvids Godjuks arvids.godj...@gmail.com wrote: There are alternative opcode cachers besides APC. For example xcache, for me, just works when APC is still catching up. I remember someone writing about APC that it is overly compex internally and due to that hard to keep up with the changes in the PHP, maybe that is not the case now. It is still the case. I for one would like to kill all the legacy features or too specific features which are really unusable by any common developers. Other developers may disagree but it makes very hard to maintain APC. Cheers, 2012/7/3 Tom Boutell t...@punkave.com Given the impracticality of using PHP without APC, it would be nice if it were part of the main if these fail, it's not ready test suite. But I suppose that's just administering beatings until morale improves (: -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?
On 07/03/2012 09:49 AM, Arvids Godjuks wrote: One one side it's good to know i'm not wrong, on the other hand it's sad in this case. Sure about one thing - xcache is worth looking at and may be a better choise than APC and has better potential. One thing sure - I haven't heard anyone complaining about xcache. And heard many complains about APC. Well, that is simply not true. We get a lot of, I tried xcache, but it didn't work, so now I am trying APC type of messages and bug reports in the APC world. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?
Just to be clear - all 3 major opcode cachers i know (zend optimizer excluded - have no idea what he has) have that shared memory cache with almost identical API. Some have extended functionality (xcache has xcache_isset(), haven't seen that in others, but have to confess i haven't been looking for some time now), so they are easily swappable. 03.07.2012 15:54 пользователь Tom Boutell t...@punkave.com написал: The ability to store your own data in the APC cache is a feature that does get used a lot in the Symfony framework world because of the availability of the sfAPCCache and whatever its Symfony 2 equivalent is. It's popular with folks who haven't felt the need to set up Redis or some other external cache yet. I'm not sure whether this is something you consider a legacy feature. On Tue, Jul 3, 2012 at 11:17 AM, Pierre Joye pierre@gmail.com wrote: hi, On Tue, Jul 3, 2012 at 5:12 PM, Arvids Godjuks arvids.godj...@gmail.com wrote: There are alternative opcode cachers besides APC. For example xcache, for me, just works when APC is still catching up. I remember someone writing about APC that it is overly compex internally and due to that hard to keep up with the changes in the PHP, maybe that is not the case now. It is still the case. I for one would like to kill all the legacy features or too specific features which are really unusable by any common developers. Other developers may disagree but it makes very hard to maintain APC. Cheers, 2012/7/3 Tom Boutell t...@punkave.com Given the impracticality of using PHP without APC, it would be nice if it were part of the main if these fail, it's not ready test suite. But I suppose that's just administering beatings until morale improves (: -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 pecl yet?
Could be, xcache is definetly dummer in features and it is its feature. I guess it helps it to keep up with releases. I will investigate this today, maybe get some interesting results worth to share here. 03.07.2012 16:54 пользователь Rasmus Lerdorf ras...@lerdorf.com написал: On 07/03/2012 09:49 AM, Arvids Godjuks wrote: One one side it's good to know i'm not wrong, on the other hand it's sad in this case. Sure about one thing - xcache is worth looking at and may be a better choise than APC and has better potential. One thing sure - I haven't heard anyone complaining about xcache. And heard many complains about APC. Well, that is simply not true. We get a lot of, I tried xcache, but it didn't work, so now I am trying APC type of messages and bug reports in the APC world. -Rasmus
