[BUG] Varien_Autoload dead lookups costly disk I/O

[kasper-agg]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

When utilizing the current way plugins are designed in general, having a substantial (hard to measure actual number) amount of plugins, the Varien_Autload will iterate over a couple of directories for each class lookup.

From a recent trace, a random page caused more than 1000 non-exisitng files, just because OM has to iterate over a couple of directories to include a file.

newfstatat: Called 772 times, and 736 of them failed (returned errors).
access: Called 449 times, and 366 of them failed.

This means that during a single tiny execution loop, PHP wasted time looking for 1,100+ files on disk that do not exist.

For an idle server, disk I/O is no issue, but on slightly higher loads, it seems this can cause quite some I/O waits, even if you're runing on SSDs.

Expected Behavior

In an ideal world, we would move all modules to composer dependencies, reducing the amount of potential paths to do lookups.

However, as long as adding code to /local and /community are supported features, I believe an intermediate solution that caches dead-ends would significantly improve unnecessary disk I/O.

Expected to have the following error numbers be reduced for a "simple" php call:

 time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 32.57    0.003490           4       772       736 newfstatat
 17.37    0.001862           4       449       366 access

Steps To Reproduce

This is a bit tricky, but having a lot of custom modules in /local and/or /community, custom layouts, translations, etc. should be sufficient to measure a difference between a vanilla OM installation.

Environment

- OpenMage: 20.14.0 and 20.18.0
- php: 8.3 and 8.4

Anything else?

I think something like this could help:

app/Mage.php

public static function autoload($class)
{
    // 1. If we already know this class doesn't exist, fail instantly
    if (function_exists('apcu_fetch') && apcu_fetch('om_miss_' . $class)) {
        return false;
    }

    // [Existing OpenMage Autoload logic happens here...]
    // It loops through paths, trying to include the file.
    
    // 2. Right before the function returns false (meaning the file wasn't found):
    if (function_exists('apcu_store')) {
        // Cache this failure for 10 minutes so PHP stops looking for it on disk
        apcu_store('om_miss_' . $class, true, 600); 
    }

    return false;
}

[kasper-agg]

I'm leaving the original post, but I think it can be even more simplified.

A working snippet relying on OPcache:

<?php

class Varien_Autoload
{
    private static ?self $instance = null;

    public static function instance(): self
    {
        return self::$instance ??= new self();
    }

    public static function register(): self
    {
        spl_autoload_register([self::instance(), 'autoload']);

        return self::instance();
    }

    public function autoload(string $class): bool
    {
        if (str_contains($class, '\\')) {
            return false;
        }

        include $this->getFilePath($class);

        return true;
    }

    private function getFilePath(string $class): string
    {
        return str_replace('_', DIRECTORY_SEPARATOR, $class) . '.php';
    }
}

• register itself as an SPL autoloader;
• ignore Composer/PSR namespaced classes;
• convert Magento-style class names to file paths;
• let PHP/OPcache handle include-path lookup and caching.

A php fpm config could look soemting like this:

opcache.validate_timestamps=0
opcache.revalidate_path=0
opcache.enable_file_override=1
realpath_cache_size=64M
realpath_cache_ttl=3600

The filesystem is stable during a PHP-FPM worker lifetime. Trust cached path/script information until deploy/release reloads PHP-FPM. That means the most efficient approach is to let PHP/OPcache do its native thing: include $path.

[kasper-agg]

Furthermore, to prevent unnecessary template checks, we have for now created a module that rewrites/extends Package.php.
The most important change:

    public function validateFile($file, array $params)
    {
        $fileName = $this->_renderFilename($file, $params);
        $testFile = (empty($params['_relative']) ? '' : Mage::getBaseDir('design') . DS) . $fileName;

        $cache = $this->getDesignFallbackCacheHelper();

        if ($cache->isKnownMissing($testFile)) {
            return false;
        }

        if (!file_exists($testFile)) {
            $cache->rememberMissing($testFile);

            return false;
        }

        return $fileName;
    }

Our helper uses our default backend cache: redis.

This cache is also cleared within our pipelines through:

        php -r "require 'pub/app/Mage.php'; Mage::app('admin')->getCacheInstance()->cleanType('config'); echo \"Config cache flushed\n\";"
        php -r "require 'pub/app/Mage.php'; Mage::app('admin')->getCacheInstance()->cleanType('layout'); echo \"Layout cache flushed\n\";"
        php -r "require 'pub/app/Mage.php'; Mage::app('admin')->getCacheInstance()->cleanType('dnatech_design_fallback_miss'); echo \"Design fallback miss cache flushed\n\";"
        
        sudo -n systemctl reload php8.4-fpm
        
        echo "PHP-FPM reloaded successfully"

Hope this helps.

With these settings, our test environments have seen pages go from 350ms to 100ms, 2000ms to 50ms and 1750ms to 320ms.
These are different types of pages, so your mileage may vary, but I think it demonstrates the potential.

[theroch]

@kasper-agg thank you for your work.

Can you please create an PR for this?

[kasper-agg]

Will do!

I'll try to reproduce the timing differences a bit more reliable.
I also haven't checked the impact of OPCache configurations, we had to change some settings. Will diff against default package settings and add it to the PR.
Also haven't checked yet what happens when OPCache is didabled, or configured with different settings and values.