Details

    • Type: Improvement
    • Status: Closed
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: 2.5
    • Fix Version/s: 2.6
    • Component/s: Libraries
    • Labels:
    • Testing Instructions:
      Hide

      I do not really know what to test here:

      1/ configure opcache
      2/ try install, upgrade, etc.
      3/ run phpunit tests
      4/ test web services
      5/ do whatever else

      Maybe it would be best if every HQ developer installed opcache and used it for master development.

      Note: you can disable the opcache easily in your moodle config.php using (you can not enable it there!)

      ini_set('opcache.enable', 0);
      

      Show
      I do not really know what to test here: 1/ configure opcache 2/ try install, upgrade, etc. 3/ run phpunit tests 4/ test web services 5/ do whatever else Maybe it would be best if every HQ developer installed opcache and used it for master development. Note: you can disable the opcache easily in your moodle config.php using (you can not enable it there!) ini_set('opcache.enable', 0);
    • Affected Branches:
      MOODLE_25_STABLE
    • Fixed Branches:
      MOODLE_26_STABLE
    • Pull from Repository:
    • Pull Master Branch:
      w28_MDL-40415_m26_opcache

      Description

      http://php.net/manual/en/book.opcache.php

      We need:

      • documentation
      • required + recommended settings
      • automatic reset and disabling

      Why? Because that is the only officially supported opcode cache in PHP 5.5.x (and even earlier versions via PECL).


      php.ini settings:

      [opcache]
      opcache.enable = 1
      opcache.memory_consumption = 128
      opcache.max_accelerated_files = 4000
      opcache.revalidate_freq = 60
       
      ; Required for Moodle
      opcache.use_cwd = 1
      opcache.validate_timestamps = 1
      opcache.save_comments = 1
      opcache.enable_file_override = 0
       
      ; If something does not work in Moodle
      ;opcache.revalidate_path = 1 ; May fix problems with include paths
       
      ; Experimental for Moodle 2.6 and later
      ;opcache.fast_shutdown = 1
      ;opcache.enable_cli = 1 ; Speeds up CLI cron
      ;opcache.load_comments = 0 ; May lower memory use, might not be compatible with addons and other apps.
      

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            skodak Petr Skoda added a comment -

            Hi Sam Hemelryk,

            I have discovered an interesting problem when running opcache in CLI mode in phpunittests - the cache writer was creating different cache.php files with the same timestamp which was breaking the includes. I have decided to add a new hack to the core_component because that could be theoretically affected too.

            I suppose the same problem may exist when sharing dataroot or cachedir, maybe the cachedir should be completely blacklisted via opcache.blacklist_filename when multiple apaches configured to use the same dataroot.

            Ciao

            Show
            skodak Petr Skoda added a comment - Hi Sam Hemelryk , I have discovered an interesting problem when running opcache in CLI mode in phpunittests - the cache writer was creating different cache.php files with the same timestamp which was breaking the includes. I have decided to add a new hack to the core_component because that could be theoretically affected too. I suppose the same problem may exist when sharing dataroot or cachedir, maybe the cachedir should be completely blacklisted via opcache.blacklist_filename when multiple apaches configured to use the same dataroot. Ciao
            Hide
            skodak Petr Skoda added a comment -

            The performance is noticeably better with opcache, on my test server 1.5s ---> 0.9s and 64MB ---> 19MB on frontpage as admin.

            Show
            skodak Petr Skoda added a comment - The performance is noticeably better with opcache, on my test server 1.5s ---> 0.9s and 64MB ---> 19MB on frontpage as admin.
            Hide
            skodak Petr Skoda added a comment -

            Hmm, if we support "opcache.validate_timestamps = 0" we would have to manually invalidate the lang php files too (and anything php in dataroot)

            Show
            skodak Petr Skoda added a comment - Hmm, if we support "opcache.validate_timestamps = 0" we would have to manually invalidate the lang php files too (and anything php in dataroot)
            Hide
            stronk7 Eloy Lafuente (stronk7) added a comment -

            Super, I'd love to kill APC from all my servers and switch to OPcache ASAP. From memory, 2 more places where special handling may be necessary:

            • lang files out from dirroot.
            • muc config out from dirroot.

            And then:

            • behat execution, requires comments to be loaded (regular expressions) to build the available "language".

            And finally, not sure if needed or no:

            • Plugin uninstall (codebase may be present/deleted).

            Looks nice!

            Show
            stronk7 Eloy Lafuente (stronk7) added a comment - Super, I'd love to kill APC from all my servers and switch to OPcache ASAP. From memory, 2 more places where special handling may be necessary: lang files out from dirroot. muc config out from dirroot. And then: behat execution, requires comments to be loaded (regular expressions) to build the available "language". And finally, not sure if needed or no: Plugin uninstall (codebase may be present/deleted). Looks nice!
            Hide
            skodak Petr Skoda added a comment -

            I have fixed:
            1/ the lang packs
            2/ plugin unisntall

            The behat init and execution seems to be running fine without code comments for me. Submitting for integration.

            To integrators: he code seems messy because we need to alter PHP opcache settings before including any libraries or classes, that is why I believe we should not try abstracting it to new library.

            Show
            skodak Petr Skoda added a comment - I have fixed: 1/ the lang packs 2/ plugin unisntall The behat init and execution seems to be running fine without code comments for me. Submitting for integration. To integrators: he code seems messy because we need to alter PHP opcache settings before including any libraries or classes, that is why I believe we should not try abstracting it to new library.
            Hide
            dougiamas Martin Dougiamas added a comment -

            Matt is looking at this for our new moodle.org cluster ... Think it will cause any problems?

            Also, can we backport this to all supported stable branches too.

            Show
            dougiamas Martin Dougiamas added a comment - Matt is looking at this for our new moodle.org cluster ... Think it will cause any problems? Also, can we backport this to all supported stable branches too.
            Hide
            skodak Petr Skoda added a comment -

            -1 for backport, I believe this needs testing and some more experienced eyes. So far admins were doing everything manually, this patch should automates everything for self-hosted sites.

            This does not resolve clustering problems because we can not invalidate op code caches on all nodes, they will always have to do it manually before upgrade and blacklist some locations.

            Show
            skodak Petr Skoda added a comment - -1 for backport, I believe this needs testing and some more experienced eyes. So far admins were doing everything manually, this patch should automates everything for self-hosted sites. This does not resolve clustering problems because we can not invalidate op code caches on all nodes, they will always have to do it manually before upgrade and blacklist some locations.
            Hide
            dougiamas Martin Dougiamas added a comment - - edited

            Sorry, I know this is nothing to do with clustering, really I just meant "production". But are you saying that as long as an admin trashes the opcode caches manually right after every php code update (eg by just restarting apache) then everything will be fine, even with 2.5.1?

            I really really think we DO need to backport at least to 2.4 and 2.5 because people will be using those for the next year or two and if it's starting to become standard we need to avoid those problems for people.

            The backport can obviously be delayed until it's all well-tested in master, obviously.

            Show
            dougiamas Martin Dougiamas added a comment - - edited Sorry, I know this is nothing to do with clustering, really I just meant "production". But are you saying that as long as an admin trashes the opcode caches manually right after every php code update (eg by just restarting apache) then everything will be fine, even with 2.5.1? I really really think we DO need to backport at least to 2.4 and 2.5 because people will be using those for the next year or two and if it's starting to become standard we need to avoid those problems for people. The backport can obviously be delayed until it's all well-tested in master, obviously.
            Hide
            skodak Petr Skoda added a comment -

            my code is not tested, it can not be backported before it gets testing with latest PHP 5.5 and PECL extension in older versions - there are multiple php.ini settings possible and we have no idea what people put there

            Show
            skodak Petr Skoda added a comment - my code is not tested, it can not be backported before it gets testing with latest PHP 5.5 and PECL extension in older versions - there are multiple php.ini settings possible and we have no idea what people put there
            Hide
            damyon Damyon Wiese added a comment -

            Backport request.

            Show
            damyon Damyon Wiese added a comment - Backport request.
            Hide
            damyon Damyon Wiese added a comment -

            Thanks Petr,

            Unit tests and install worked fine for me with these changes. Integrated to master only (and backport request added).

            Show
            damyon Damyon Wiese added a comment - Thanks Petr, Unit tests and install worked fine for me with these changes. Integrated to master only (and backport request added).
            Hide
            smithrn Ryan Smith added a comment - - edited

            +1 for a backport. We have been running Opcache for a few months in production now. We started with the official PECL version for PHP 5.4.x and just moved to the PHP 5.5 version two weeks ago. We haven't experienced any major problems with Opcache. It is much more stable than our previous accelerator, Wincache. We are using the settings recommended by the developers, here: https://github.com/zendtech/ZendOptimizerPlus/

            Show
            smithrn Ryan Smith added a comment - - edited +1 for a backport. We have been running Opcache for a few months in production now. We started with the official PECL version for PHP 5.4.x and just moved to the PHP 5.5 version two weeks ago. We haven't experienced any major problems with Opcache. It is much more stable than our previous accelerator, Wincache. We are using the settings recommended by the developers, here: https://github.com/zendtech/ZendOptimizerPlus/
            Hide
            fred Frédéric Massart added a comment -

            So far I am unable to test this... OPcache does not work properly in my environment, Moodle (but also Adminer) sends back an empty response from the server.

            fred@fred:~$ curl -i http://fred.moodle.local/im/
            HTTP/1.1 200 OK
            Date: Wed, 10 Jul 2013 03:23:40 GMT
            Server: Apache/2.2.22 (Ubuntu)
            X-Powered-By: PHP/5.3.10-1ubuntu3.6
            Set-Cookie: MoodleSession=b1dh4bm927n37grjadkk6o4lk7; path=/im/
            Expires: Mon, 20 Aug 1969 09:23:00 GMT
            Cache-Control: no-store, no-cache, must-revalidate
            Pragma: no-cache
            Content-Language: en
            Content-Script-Type: text/javascript
            Content-Style-Type: text/css
            X-UA-Compatible: IE=edge
            Cache-Control: post-check=0, pre-check=0
            Last-Modified: Wed, 10 Jul 2013 03:23:40 GMT
            Accept-Ranges: none
            X-Frame-Options: sameorigin
            Vary: Accept-Encoding
            Transfer-Encoding: chunked
            Content-Type: text/html; charset=utf-8
             
            // Some HTML here...
            curl: (18) transfer closed with outstanding read data remaining
            </html>fred@fred:~$
             
            fred@fred:~$ curl -I http://fred.moodle.local/im/
            curl: (52) Empty reply from server
            fred@fred:~$

            fred@fred:~$ php -v
            PHP 5.3.10-1ubuntu3.6 with Suhosin-Patch (cli) (built: Mar 11 2013 14:31:48) 
            Copyright (c) 1997-2012 The PHP Group
            Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
                with Zend OPcache v7.0.2, Copyright (c) 1999-2013, by Zend Technologies
                with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
             
            // Settings I played with...
            zend_extension=/usr/lib/php5/20090626/opcache.so
            opcache.memory_consumption=128
            opcache.interned_strings_buffer=8
            opcache.max_accelerated_files=10000
            opcache.revalidate_freq=60
            opcache.fast_shutdown=1
            opcache.enable_cli=1
            ;opcache.enable=0
            opcache.error_log=/var/log/opcache.log
            opcache.log_verbosity_level=4
            ;opcache.max_file_size=1
            opcache.revalidate_path=1
            opcache.save_comments=1

            Somehow the logging does not work...

            Show
            fred Frédéric Massart added a comment - So far I am unable to test this... OPcache does not work properly in my environment, Moodle (but also Adminer) sends back an empty response from the server. fred@fred:~$ curl -i http://fred.moodle.local/im/ HTTP/1.1 200 OK Date: Wed, 10 Jul 2013 03:23:40 GMT Server: Apache/2.2.22 (Ubuntu) X-Powered-By: PHP/5.3.10-1ubuntu3.6 Set-Cookie: MoodleSession=b1dh4bm927n37grjadkk6o4lk7; path=/im/ Expires: Mon, 20 Aug 1969 09:23:00 GMT Cache-Control: no-store, no-cache, must-revalidate Pragma: no-cache Content-Language: en Content-Script-Type: text/javascript Content-Style-Type: text/css X-UA-Compatible: IE=edge Cache-Control: post-check=0, pre-check=0 Last-Modified: Wed, 10 Jul 2013 03:23:40 GMT Accept-Ranges: none X-Frame-Options: sameorigin Vary: Accept-Encoding Transfer-Encoding: chunked Content-Type: text/html; charset=utf-8   // Some HTML here... curl: (18) transfer closed with outstanding read data remaining </html>fred@fred:~$   fred@fred:~$ curl -I http://fred.moodle.local/im/ curl: (52) Empty reply from server fred@fred:~$ fred@fred:~$ php -v PHP 5.3.10-1ubuntu3.6 with Suhosin-Patch (cli) (built: Mar 11 2013 14:31:48) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies with Zend OPcache v7.0.2, Copyright (c) 1999-2013, by Zend Technologies with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans   // Settings I played with... zend_extension=/usr/lib/php5/20090626/opcache.so opcache.memory_consumption=128 opcache.interned_strings_buffer=8 opcache.max_accelerated_files=10000 opcache.revalidate_freq=60 opcache.fast_shutdown=1 opcache.enable_cli=1 ;opcache.enable=0 opcache.error_log=/var/log/opcache.log opcache.log_verbosity_level=4 ;opcache.max_file_size=1 opcache.revalidate_path=1 opcache.save_comments=1 Somehow the logging does not work...
            Hide
            matt.clarkson Matt Clarkson added a comment -

            Dynamically generated PHP files could be versioned or content hash named so that op-code caching could be done with stat turned off.

            Show
            matt.clarkson Matt Clarkson added a comment - Dynamically generated PHP files could be versioned or content hash named so that op-code caching could be done with stat turned off.
            Hide
            phalacee Jason Fowler added a comment -

            Ubuntu 12.04's PHP with Suhosin conflicts with the Opcache extension available through PECL. Matt attempted to solve this issue for us, but was unable to do so.

            Show
            phalacee Jason Fowler added a comment - Ubuntu 12.04's PHP with Suhosin conflicts with the Opcache extension available through PECL. Matt attempted to solve this issue for us, but was unable to do so.
            Hide
            skodak Petr Skoda added a comment -

            Perfect, this is what we need to know. I read about some problems with xhprof order of extensions and php.

            Show
            skodak Petr Skoda added a comment - Perfect, this is what we need to know. I read about some problems with xhprof order of extensions and php.
            Hide
            poltawski Dan Poltawski added a comment -

            "Maybe it would be best if every HQ developer installed opcache and used it for master development"

            Because we did this with apc? weird thing to say.

            Show
            poltawski Dan Poltawski added a comment - "Maybe it would be best if every HQ developer installed opcache and used it for master development" Because we did this with apc? weird thing to say.
            Hide
            poltawski Dan Poltawski added a comment -

            Was simple for me to install with homebrew, and all looks good.

            Show
            poltawski Dan Poltawski added a comment - Was simple for me to install with homebrew, and all looks good.
            Hide
            skodak Petr Skoda added a comment -

            Hmm, if it looks all good with normal settings we may try those marked experimental above and even those risky ones like opcache.validate_timestamps = 0, opcache.enable_file_override = 1 and see if we can add some hacks to make them work reliably because they would speed things up even more.

            Show
            skodak Petr Skoda added a comment - Hmm, if it looks all good with normal settings we may try those marked experimental above and even those risky ones like opcache.validate_timestamps = 0, opcache.enable_file_override = 1 and see if we can add some hacks to make them work reliably because they would speed things up even more.
            Hide
            damyon Damyon Wiese added a comment -

            I tested this with on 5.3 with defaults and it was working for me.

            Show
            damyon Damyon Wiese added a comment - I tested this with on 5.3 with defaults and it was working for me.
            Hide
            damyon Damyon Wiese added a comment -

            a single bug fix
            a drop in a waterfall
            hear the mighty roar

            Thanks for your contribution!

            Show
            damyon Damyon Wiese added a comment - a single bug fix a drop in a waterfall hear the mighty roar Thanks for your contribution!
            Hide
            tsala Helen Foster added a comment -

            Thanks Petr for providing docs too - http://docs.moodle.org/26/en/OPcache looks really good!

            Show
            tsala Helen Foster added a comment - Thanks Petr for providing docs too - http://docs.moodle.org/26/en/OPcache looks really good!
            Hide
            danielneis Daniel Neis added a comment -

            Hello,

            here at Universidade Federal de Santa Catarina, Brazil, we are having serious problems with the opcache reset done by admin/index.php

             57 if ((isset($_GET['cache']) and $_GET['cache'] === '0')
             58         or (isset($_POST['cache']) and $_POST['cache'] === '0')
             59         or (!isset($_POST['cache']) and !isset($_GET['cache']) and empty($_GET['sesskey']) and empty($_POST['sesskey']))) {
             60     // Prevent caching at all cost when visiting this page directly,
             61     // we redirect to self once we known no upgrades are necessary.
             62     // Note: $_GET and $_POST are used here intentionally because our param cleaning is not loaded yet.
             63     // Note2: the sesskey is present in all block editing hacks, we can not redirect there, so enable caching.
             64     define('CACHE_DISABLE_ALL', true);
             65
             66     // Force OPcache reset if used, we do not want any stale caches
             67     // when detecting if upgrade necessary or when running upgrade.
             68     if (function_exists('opcache_reset')) {
             69         opcache_reset();
             70     }
             71     $cache = 0;
             72
             73 } else {
             74     $cache = 1;
             75 }
            

            As we have about 10 Moodle installed on same server, this opcache_reset() call affects all installations and everytime we have to install a new plugin or update anything this causes Nginx to timeout and a big load on server as all 10K+ files will have to be "recompiled".

            We have tried to substitute opcache_reset() with opcache_invalidate($CFG->dirroot) and it seems to work, but we had not tested very well.

            Any ideas?

            Kind regards,
            Daniel

            Show
            danielneis Daniel Neis added a comment - Hello, here at Universidade Federal de Santa Catarina, Brazil, we are having serious problems with the opcache reset done by admin/index.php 57 if ((isset($_GET['cache']) and $_GET['cache'] === '0') 58 or (isset($_POST['cache']) and $_POST['cache'] === '0') 59 or (!isset($_POST['cache']) and !isset($_GET['cache']) and empty($_GET['sesskey']) and empty($_POST['sesskey']))) { 60 // Prevent caching at all cost when visiting this page directly, 61 // we redirect to self once we known no upgrades are necessary. 62 // Note: $_GET and $_POST are used here intentionally because our param cleaning is not loaded yet. 63 // Note2: the sesskey is present in all block editing hacks, we can not redirect there, so enable caching. 64 define('CACHE_DISABLE_ALL', true); 65 66 // Force OPcache reset if used, we do not want any stale caches 67 // when detecting if upgrade necessary or when running upgrade. 68 if (function_exists('opcache_reset')) { 69 opcache_reset(); 70 } 71 $cache = 0; 72 73 } else { 74 $cache = 1; 75 } As we have about 10 Moodle installed on same server, this opcache_reset() call affects all installations and everytime we have to install a new plugin or update anything this causes Nginx to timeout and a big load on server as all 10K+ files will have to be "recompiled". We have tried to substitute opcache_reset() with opcache_invalidate($CFG->dirroot) and it seems to work, but we had not tested very well. Any ideas? Kind regards, Daniel
            Hide
            skodak Petr Skoda added a comment -

            Cached files may be in other directories too, doing for dirroot only is not enough. Anyway please create a new issue if necessary.

            Show
            skodak Petr Skoda added a comment - Cached files may be in other directories too, doing for dirroot only is not enough. Anyway please create a new issue if necessary.

              People

              • Votes:
                1 Vote for this issue
                Watchers:
                15 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Fix Release Date:
                  18/Nov/13