git clone -b dev-filecache 'https://github.com/TerryE/opcache.git
cd opcache
/usr/share/php-5.4-shell/bin/./phpize
./configure --enable-opcache -enable-opcache-file-cache --with-php-config=/usr/share/php-5.4-shell/bin/php-config
make
/bin/sh /home/naox/opcache/libtool --mode=compile cc -I. -I/home/naox/opcache -DPHP_ATOM_INC -I/home/naox/opcache/include -I/home/naox/opcache/main -I/home/naox/opcache -I/usr/share/php-5.4-shell/include/php -I/usr/share/php-5.4-shell/include/php/main -I/usr/share/php-5.4-shell/include/php/TSRM -I/usr/share/php-5.4-shell/include/php/Zend -I/usr/share/php-5.4-shell/include/php/ext -I/usr/share/php-5.4-shell/include/php/ext/date/lib -DHAVE_CONFIG_H -O2 -c /home/naox/opcache/zend_accelerator_util_funcs.c -o zend_accelerator_util_funcs.lo
cc -I. -I/home/naox/opcache -DPHP_ATOM_INC -I/home/naox/opcache/include -I/home/naox/opcache/main -I/home/naox/opcache -I/usr/share/php-5.4-shell/include/php -I/usr/share/php-5.4-shell/include/php/main -I/usr/share/php-5.4-shell/include/php/TSRM -I/usr/share/php-5.4-shell/include/php/Zend -I/usr/share/php-5.4-shell/include/php/ext -I/usr/share/php-5.4-shell/include/php/ext/date/lib -DHAVE_CONFIG_H -O2 -c /home/naox/opcache/zend_accelerator_util_funcs.c -fPIC -DPIC -o .libs/zend_accelerator_util_funcs.o
/home/naox/opcache/zend_accelerator_util_funcs.c: In function ‘zend_prepare_function_for_execution’:
/home/naox/opcache/zend_accelerator_util_funcs.c:613: error: ‘ZEND_ACC_ALIAS’ undeclared (first use in this function)
/home/naox/opcache/zend_accelerator_util_funcs.c:613: error: (Each undeclared identifier is reported only once
/home/naox/opcache/zend_accelerator_util_funcs.c:613: error: for each function it appears in.)
make: **\* [zend_accelerator_util_funcs.lo] Error 1
I tried same with with original opcache (https://github.com/zendtech/ZendOptimizerPlus.git) - no problems with compilation there. PHP version in use is 5.4.16.
Also I've been thinking that not many users found this project because MLC does not suggest filecache at all. It probably should me called it something like zend file-opcache mod
@naox, this is linked to https://github.com/zendtech/ZendOptimizerPlus/issues/102
I needed to change a version test on an bit of conditional code that only needs to be applied to PHP 5.4.1 through 5.4.10 and not all 5.4.x versions, as the 5.4.11+ implementation of traits is really the 5.5 version released on the QT. I've done this on my local git version but not pushed it to github. I am off to bed now so will do this tomorrow. Sorry.
@naox, I am keen to help you get started testing MLC opcache, and to that end open a 1-1 dialogue / chat, as well as using this public issues vehicle. If you are happy to, why not ping me an email to terry at ellisons dot org dot uk and I can also pass you my Skype / google credentials if you want to chat. I also would like to understand your target environment better and it's difficult doing this through issue posts :-)
I'm a small hosting provider and customers and have been bugging me for apc for years now. I use mod_fcgi - not php_fpm - to start php fcgi handlers. I've tested apc with separate cache for each handler but server load (io load) was even worse. I'm reluctant to switch to php_fpm as centralized process to start other php process-es seem like bad idea - php handler segfaults caused by php extensions are common (due to bugs in libs compiled against ususaly) - dunno how it would work out in php_fpm. Also mod_fcgi makes it real easy to provide new versions of php, started with separate php.ini's and to limit maximum number of handlers per system user.
I did not even know about zend opcache before I've read about it on php 5.5 beta announcement. Seeing that you fork does not get any attention (so it might go zombie like it often happens) I wanted to test it, report bugs and make development go forward.
I've rewrited a way of providing php.ini's in past 2 days (like I've mentioned in another ticket) (10+h work :/). Now it is compilant with selectively running opcache and it is more clear to end users about what happens behind curtains (now it: php_profile=php_version+php_ini , assign php_profiles to domains(vhosts))
I was thinking that i've
1) test opcache on some test sites
2) enable opcache for all customers for maybe 10 minutes during the night and observe overall server load (io load, cpu load) on 12 machines. Also I've would randomly browse customer webstites looking for php errors on it.
3) provide option for customers to enable opcache for their selected domains (marked as experimental)
4) in future: enable opcache by default
3) and 4) depends on observed gains with server load (I don't care too much about litle speedup in page generation time). Especialy I've would like to achieve lower io load (then lower cpu load, then lower memory usage, and then page generation speed).
There is no rush. You can take all the time you need to code. I hope filecache will be in future integrated into original zend opcache and thus in php 5.5
Maybe not many users found this project because MLC does not suggest filecache at all. Maybe naming it (zend) file-opcache would be better idea...
@naox, there is a debate that needs to be made elsewhere about the pros and cons of **fpm** vs **fcgi**, because (as you point out) they do currently address separate scaling sweet spots, and IMO this discussion is worth having.
I consider the MLC fork of OPcode still an alpha code variant which is still a technology demonstrator, so I feel it premature to expose it to end customers at this stage. My aim is to kill the fork rather than let it zombie, but only after the core OPcache team have used it to backload the technology into mainstream OPcache. IMO, the core MLC algos are solid and shave roughly 80% of the compilation CPU load and more of the I/O load off scripts executed in non-SMA SAPIs. This level of performance is compelling enough for the core team to consider.
The functional main issues that need resolving relate to the caches themselves, as they are "binary" files which in many ways the equivalent of an EXE file for conventional 3GLs.
- They have to be named and created somewhere and this means that the script needs R/W access to the directory that they are stored in. IMO, storing them in the same directory as the scripts themselves is not the
best option. There needs to be some simple-to-use configuration INI setting which allows this to be done. My current **cache_pattern** / **cache_file** provides the basic functionality, but isn't novice-friendly. Perhaps a simpler alternative would be to allow an alternative **cache_root** directory which would mirror **DOCUMENT_ROOT** so that **DOCUMENT_ROOT/subdir/script.php** would use the cache file **CACHE_ROOT/subdir/script.opcache**, etc. This would allow the cache file to be stored in a R/W directory hierarchy not directly accessible via URI based web requests, etc.
- The failure modes need to be thought through. For example at the moment, if a script doesn't have write access to the cache directory, then any attempt to create a cache will generate an error and in practice this will halt the script execution. Should this be a warning, with the script defaulting to non-cached mode?
So what I am suggesting is that you try MLC opcache on some test sites to see if you find it usable from a configuration perspective and performing generally as I claim. Note that at the moment I only support the **cli** and **cgi** SAPIs. These only execute one request per image activation. I am planning to add proper fastcgi (as in **--enable-fastcgi**) support but this is still in the planning stage.
BTW, the reason that I call it **MLC** is that it really is layered on OPcache. OPcache does most of the hard work, and the file-cache element only comes into play to fill memory cache.
> IMO, the core MLC algos are solid and shave roughly 80% of the compilation CPU load and more of the I/O load off scripts executed in non-SMA SAPIs. This level of performance is compelling enough for the core team to consider.
I agree. However you may remember that Rasmus was quite resistant to the idea of disk-based cache when I raised it a few months ago, and doesn't want to consider it. You'll have some convincing to do but hopefully that will be done by itself if it proves successful (which I think it will).
I think this project/fork is worth being advertised more at this stage. Sorry for offtopic.
@normadize, the whole thread is off-topic ;-? IIRC, Rasmus position was based on the assertion that no one had successfully demonstrated that a file-based caching implementation that performed well. This implementation does that, so maybe he will consider his position. I'd better close this one because I did fix @naox initial problem. :-)