From: normadize at gmail dot com Operating system: PHP version: 5.5.0beta1 Package: opcache Bug Type: Feature/Change Request Bug description:BIG Request: files or memcached based storage (please read before dismissing)
Description: ------------ Now that Zend Optimizer Plus will make it to 5.5, I think it's time to resurface this discussion. PLEASE do read it before dismissing it. Time changed. There are a lot of SuPHP (and the likes) installations out there that suffer from horrible performance ... and as we know, all current opcode cachers fail. SuPHP and the likes now account for quite a lot of php installations, a really non-negligible number. All those installations would greatly benefit from a storage engine that survives between requests. Both users and hosting providers would be extremely grateful! There are so many slow and badly written but still very popular scripts out there cough like WordPress cough, especially when they have all sort of other popular and slow plugins being executed as part of a single request. This tends to be the norm now with websites based on WordPress, Drupal, etc ... and a ton of them are hosted in SuPHP setups. I know the cons of file-based storage but let's reconsider it for a moment. MEMCACHED. would be a nice solution but most probably (especially for SuPHP environments), hosting providers won't allow it or won't provide it at all since it would be a memory hog as clients fill up the server's RAM with cached php opcode. It would still be great to have as a storage engine though. FILE-BASED. Everybody says cache hits would be slow. And yes, they would slower than SHM. However: it would still be considerably faster than loading and executing an entire chain of scripts long scripts, e.g. WordPress + tons of plugins (all those php files have to be read anyway without an opcode cacher) The OS would cache the opcode files transparently in its file cache -- and hosting providers will not disable that as they don't want their disks thrashed -- so this would actually be pretty much as fast as SHM-based solutions as long as the files are in the OS's file cache. On average, it would still be considerably faster than without any opcode cache at all ... probably on par with a Memcached-based cache which incurs network latency. The OS would automatically take care of wiping the oldest accessed files from its file cache when memory fills up, so garbage collection would be pretty simple. This solution would be great since the server's memory won't be hogged (as opposed to memcached or SHM-based solutions), and it would not require any dependencies for it to run (as opposed to memcached). Both users and providers alike would enjoy a faster service + less resources hogged. It would be a great compromise for those numerous SuPHP-and-friends setups. I know that tons of people would employ such a solution if it existed! Hoping you'll consider this. Cheers. p.s. I remember when eAccelerator had file-based storage and it was making a great deal of difference for such big and slow scripts. Now there is no PHP opcode cache (that I know of) which works with SuPHP. -- Edit bug report at https://bugs.php.net/bug.php?id=64502&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64502&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64502&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64502&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64502&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64502&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64502&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64502&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64502&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=64502&r=support Expected behavior: https://bugs.php.net/fix.php?id=64502&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64502&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64502&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64502&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64502&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64502&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64502&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=64502&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64502&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64502&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64502&r=mysqlcfg