Re: encode php scripts with opcache compatibility

From: Date: Thu, 22 May 2014 19:18:52 +0000
Subject: Re: encode php scripts with opcache compatibility
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-74433@lists.php.net to get a copy of this message
2014-05-21 12:20 GMT+02:00 Nicolai Scheer <nicolai.scheer@gmail.com>: > Hi all, > > I'm currently facing the situation, that I need to protect my php sources > and retain opcache compatibility. > Basically it would be ok to just dump the _zend_op_array struct (defined in > zend_compile.h) to a file and make the zend engine able to load it again. > Once it is loaded, it could be server from opcache. > Is there any solution for my situation? > Are there any plans to add the "serialize opcode to string, dump string to > file and load it again"-functionality to php? > How easy would it be to add this functionality? > > Maybe there are already functions I don't know about to ease this process ? you should look at https://github.com/TerryE/opcache by Terry Ellison and https://github.com/TerryE/opcache/wiki has many information about serializing/deserializing opcode This MLC Opcache is targeted at cli/cgi workloads (it loads cache from the file and fixes memory references). In Your scenario if You prepare a file with complete cache, and disable file existence/mtime checking in the opcache ini files this might be sufficient to achieve Your goal eaven if you use fcgi. The only problem might be the support for fastcgi/mod_php sapi, IMHO it will load a cache file based on the first request and behave like a regular opcache for the next requests but YMMV (I have loked at this some time ago). Alternatively if You are a brave person, or like some might say crazy ;) You might try my fork https://github.com/lazy404/ZendOptimizerPlus/tree/fcgid (check wiki for config directions). It supports memory reclamation (when cache is recycled), loading cache from a file (works best when the file is on tmpfs), sharing cache between php processes started by an external process manager (like mod_fcgid). A more "polished" version is used to serve thousands websites with millions of total request's daily. The bad part is that it is a hack done fast, documentation is non existent, the code is very ugly, I'm not sure if locking is implemented correctly, and there are no deadlock detection. It was only done to check if it was possible to make opcache work with mod_fcgid (parts of code ware taken from TerryE's fork). There are some known issues (sometimes php crash corrupts the cache, the code on github is old and has some known minor bugs which are fixed elsewhere). The idea behind this fork is simple 1) use opcode reference address fixing from MLC Opcache 2) store the result in a fixed address in a memory region backed by a mmaped tmpfs file (on linux this allows using madvise() to nuke the cache and return the memory to the os) -- Michal Grzedzicki

« previous php.internals (#74433) next »