Possible race condition

  • Resolved labbapo11

    (@labbapo11)


    1 month, 1 week ago

    Hi,

    We exprienced twice now since 26.04.03 a condition where the server load rises steadily until we disable docket-cache.

    Initially, there are thousands of,

    ::1 – – [11/Apr/2026:10:46:20 +0200] “POST /wp-json/docket-cache/v1/opcache-invalidate HTTP/1.1” 200 52 “-” “Mozilla/5.0 (compatible; docket-cache/26.04.03; +https://docketcache.
    com)”

    then eventually,

    ::1 – – [11/Apr/2026:10:46:33 +0200] “POST /wp-json/docket-cache/v1/opcache-invalidate HTTP/1.1” 404 117 “-” “Mozilla/5.0 (compatible; docket-cache/26.04.03; +https://docketcache
    .com)”

    and the server load is way above average, over 1.2M lines like the two above were found in two hours time.

    The basics of the config below but I’m happy to provide more info. The “::1” tells me IPv6 ised used which is a bit of surprise.

    Server Apache 2.4 PHP 8.2 with php-fpm
    Woocommerce
    DOCKET_CACHE_MAXFILE’, 165000
    Disk size memory based 2G, we usually are below 1G
    Cron is OS based once per minute
    PHP Memory Limit 4G
    WP Frontend Memory Limit 2G
    WP Backend Memory Limit 4G
    At this moment:
    Zend OPcache 531M memory of 101684 files

    Thanks,

    Per

    The page I need help with: [log in to see the link]

Viewing 2 replies - 1 through 2 (of 2 total)
  • Plugin Author Nawawi Jamili

    (@nawawijamili)

    1 month, 1 week ago

    Hi, thanks for the report.

    Add this constant in wp-config.php

    define('DOCKET_CACHE_WPCLI_OPCACHE', false);

    it will disable the check.

    Thanks.

    Plugin Author Nawawi Jamili

    (@nawawijamili)

    1 month, 1 week ago

    Quick update – I found the cause and opened a report on GitHub:

    https://github.com/nawawi/docket-cache/issues/29

    What happens:

    The new CliOpcache feature in 26.04.03 sends one small HTTP request
    for every cache file that WP-CLI removes. Normally this is fine, but
    during garbage collection (the routine cleanup of old cache files)
    many files are removed one after another. On your site, with
    WooCommerce and cron running every minute, this creates thousands
    of requests every minute. The server becomes very busy, and the load
    keeps going up until the plugin is disabled.

    The 404 errors you saw later are a side effect. When the server is
    too busy, some requests cannot finish loading the plugin in time, so
    the address is not found. It is not a separate issue.

    The constant I gave in my last reply will stop this from happening
    while you wait for the fix. The fix will be in version 26.04.04. It
    will group the requests together and send only one per command,
    instead of one per file.

    Thanks again for the detailed log; it made this straightforward to diagnose.

Viewing 2 replies - 1 through 2 (of 2 total)

You must be logged in to reply to this topic.