Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:74433 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 9916 invoked from network); 22 May 2014 19:18:57 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 May 2014 19:18:57 -0000 Authentication-Results: pb1.pair.com header.from=lazy404@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=lazy404@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.51 as permitted sender) X-PHP-List-Original-Sender: lazy404@gmail.com X-Host-Fingerprint: 209.85.215.51 mail-la0-f51.google.com Received: from [209.85.215.51] ([209.85.215.51:50102] helo=mail-la0-f51.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 49/46-63132-0AD4E735 for ; Thu, 22 May 2014 15:18:57 -0400 Received: by mail-la0-f51.google.com with SMTP id gf5so3057486lab.10 for ; Thu, 22 May 2014 12:18:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ukJbYEnr7M8RAmTDH1+ILjyCVOYsIce3Gv7fuubDyVY=; b=Pm5FcUM0CgcswsiNfCyOXVB+60LX3bTBJ+0O4RYR5b5Lveu6DUf4afCe/Xwwn0R1xX RcAn6H2dQBJJqCol1j/ImrfARBkXHQpdFYpl07T4tvCtZWlopv3njzuP8XZwAaAKBTRB CgZ+i/1MPADN+qF0b/aZu1TextNwbTmJ1a/nchyJOBNjP+rRcuqI0PHIqHiIdQua03WE lkI4sRBLVX6CK7HB1cwwQ44TsevfQwW6qTESYxcjhZ3bwBN/8QlbWQuA0OI0c41uufBa 5xvpd7DsheYodAjscopfjKJiaS3GBpWydZbpypLxHQKfhHB9v1jUzSrgcAGG/keDjXd2 nStg== MIME-Version: 1.0 X-Received: by 10.112.72.230 with SMTP id g6mr23794002lbv.10.1400786332592; Thu, 22 May 2014 12:18:52 -0700 (PDT) Received: by 10.152.2.227 with HTTP; Thu, 22 May 2014 12:18:52 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 May 2014 21:18:52 +0200 Message-ID: To: Nicolai Scheer Cc: PHP Internals Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] encode php scripts with opcache compatibility From: lazy404@gmail.com (Lazy) 2014-05-21 12:20 GMT+02:00 Nicolai Scheer : > 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