Backend Development 6 min read

Investigating Intermittent Memcache set/add Failures in PHP Memcache Extension 2.2.7

The intermittent set/add failures observed with PHP’s Memcache extension 2.2.7 are caused by its built‑in 15‑second retry interval (MMC_DEFAULT_RETRY = 15) that marks the connection permanently failed after a poll timeout, and can be resolved by specifying the hidden fourth ‘timeoutms’ parameter, adjusting php.ini, or migrating to the newer Memcached extension.

37 Interactive Technology Team
37 Interactive Technology Team
37 Interactive Technology Team
Investigating Intermittent Memcache set/add Failures in PHP Memcache Extension 2.2.7

Background : A server using the PHP Memcache extension started to experience frequent set / add failures after deployment.

Test : To reproduce the issue, a simple script test_mc.php was written (the script content is shown in the original images). Running the script repeatedly showed that failures occur in bursts of 15 consecutive setfail messages.

Investigation : The strace tool was used to trace system calls while executing the script. The trace revealed two distinct patterns: successful setsuccess calls (green) and failed setfail calls (red). The first failure was caused by a poll timeout of 1000 ms. The subsequent 14 failures occurred without any network request, indicating that the client considered the connection permanently failed during that interval.

Why does the failure happen exactly 15 times? By examining the Memcache extension source code (version 2.2.7), a constant named MMC_DEFAULT_RETRY with the value 15 was found. In the mmc_open function, when a connection enters the MMC_STATUS_FAILED state, the client must wait 15 seconds before attempting to reconnect. During this waiting period, all Memcache calls automatically fail, which explains the 15 consecutive failures.

How to adjust the timeout? The official documentation ( php.net/manual/zh/memcache.connect.php ) shows that the third parameter of Memcache::connect() sets the timeout in seconds. However, the source code reveals that the extension actually supports a fourth hidden parameter timeoutms (milliseconds). If timeoutms is provided and greater than zero, it overrides the second timeout value. When only the third parameter is supplied, timeoutms defaults to default_timeout_ms (1000 ms), causing the timeout to remain at 1 second regardless of the third‑parameter value.

To correctly set a longer timeout, the fourth parameter must be used, e.g., Memcache::connect($host, $port, $timeout, $timeoutms) where $timeoutms is the desired value in milliseconds (e.g., 3000 for 3 seconds). After modifying the script and verifying with strace , the new timeout took effect.

Alternative solutions : The timeout can also be changed globally via php.ini or at runtime using ini_set() . Additionally, switching from the older Memcache extension to the newer Memcached extension is recommended, though data compatibility (serialization format) must be considered.

Conclusion : The intermittent failures are caused by the built‑in 15‑second retry interval in Memcache 2.2.7. Properly setting the hidden timeoutms parameter or using the newer Memcached extension resolves the issue.

BackendPHPDebuggingConnection Timeoutmemcache
37 Interactive Technology Team
Written by

37 Interactive Technology Team

37 Interactive Technology Center

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.