While working on a development instance I installed the stripe payment module and then ran

php bin/magento setup:di:compile

I hadn't previously done this on this install and it's been running for over a month totally stable and with acceptable performance for a small aws instance. However since this was run the performance of the system has dropped to unacceptable levels and pins php7.2-fpm to 100%.

It's so slow even the cron jobs start backing up and consuming more and more cpu time.

Any ideas what might be going on and what I can do to debug it?

EDIT I've added new relic onto the system and can see the following

Category    Slowest components  Count   Duration    %
Custom  Magento\Framework\Config\Dom::_mergeNode    731 38,700 ms   53%
Custom  Magento\Framework\Config\Reader\Filesystem::_readFiles  18  7,950 ms    11%
Custom  Magento\Framework\Config\Dom::_getMatchedNode   113 5,020 ms    7%
Custom  Magento\Framework\Config\Dom::validateDomDocument   8   2,790 ms    4%
Custom  Magento\Framework\ObjectManager\Config\Mapper\Dom::convert  7   2,740 ms    4%
Custom  Magento\WebapiAsync\Code\Generator\Config\RemoteServiceReader\Communication::read   1   2,570 ms    4%
Remainder   Remainder   1   12,700 ms   18%
Total time          72,500 ms   100%
  • 2
    First check your current instance mod is production/ develop.Also Some when we install new extension then check cache is disabled at the system.If yes then you need to enable all cache also mod should be production.
    – Amit Bera
    Aug 4, 2019 at 8:04
  • Amit, the performance is the same in develop or production, the cache is enabled also
    – Matthew
    Aug 4, 2019 at 8:06
  • but performance should better at production than the develop. Please check bot attack happening on your system. I have faced performance issue due a large amount of bot attach and it has been resolved by add web firewall / & upgrade /applied magento patches
    – Amit Bera
    Aug 4, 2019 at 8:11
  • This is a development system not connected to the wider internet so no not a bot attack.
    – Matthew
    Aug 4, 2019 at 8:46
  • Have you looked into size of php fpm worker count. Although you've not said whether your dev is using production data or not. Could be you've reached a point in terms of data i.e. number of categories vs products which requires more resource Aug 4, 2019 at 21:11

2 Answers 2


Edited - This didn't work

Finally found the solution to this, it appears the for some reason when doing the di compile the system had turned the cache off or somehow otherwise invalidated it but the status still showed as on when doing

php /bin/magento cache:status

I fixed it by running

php bin/magento cache:disable
php bin/magento cache:enable
php bin/magento setup:upgrade

This seems to have reset everything back to a working state.

update So this seemed to work for a short period, performance then reverted to very poor levels. I've disabled all 3rd party and custom modules, cleared the cache, deleted the generated/ folder, tried default mode, developer mode and production to no effect.

  • Awesome. The admin shows all green but everything was set to 0. Now set to 1 and cron runs in 2s instead of 20 :) Jan 24, 2020 at 3:52
  • Have you solved the other issues ? Jan 24, 2020 at 3:54

I ran into the same issue and it turned out it was caused by running composer update as described in this bug report: https://github.com/magento/magento2/issues/17634#issuecomment-492500726

You can sometimes fix it by running bin/magento cache:enable, but sometimes you'll need to go into env.php and manually edit the cache_types section to look like this:

    'cache_types' => [
        'config' => 1,
        'layout' => 1,
        'block_html' => 1,
        'collections' => 1,
        'reflection' => 1,
        'db_ddl' => 1,
        'eav' => 1,
        'customer_notification' => 1,
        'config_integration' => 1,
        'config_integration_api' => 1,
        'target_rule' => 1,
        'full_page' => 1,
        'config_webservice' => 1,
        'translate' => 1,
        'compiled_config' => 1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.