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


Thread (32 messages)

« previous php.internals (#74433) next »