(Sigh.) After applying recent upgrades to our Red Hat 5 server at work, suddenly PHP file locking blocks the script execution for exactly 30 seconds! Both a shared reading lock (LOCK_SH) and exclusive writing lock (LOCK_EX) do this. This was, shall we say, unpleasant to diagnose. Since we use Cache_Lite (which locks by default) to cache lots of stuff and sometimes in multiple layers, most of our pages suddenly took 30, 60, etc. seconds to load! Here were duration times from a test script:
'write' => '0.00257301', 'read' => '0.00039792', 'write w/ exclusive lock' => '30.00274611', (file_put_contents w/ LOCK_EX) 'fopen' => '0.00080800', 'get shared lock' => '29.99504590', (flock w/ LOCK_SH) 'read file' => '0.00034904', 'close file' => '0.00005412',
Awesome. Now it is documented that flock() “will not work on NFS” (which we are on), but this has worked fine for over a year and continues to work on our unpatched server. The versions of Apache and PHP did not seem to change. Here’s how Red Hat listed them:
old: httpd-2.2.3-6.el5 new: httpd-2.2.3-11.el5_1.3
old: php-5.1.6-12.el5 new: php-5.1.6-20.el5_2.1
So… any ideas? I’ll have to turn off fileLocking in Cache_Lite to move forward, but I’d love to know what’s up. This especially troubles me because I recently added default cache locking to Minify. Locking is also the default in Zend_Cache_Backend_File, so it seems like the right thing to do.
Hi, I’m the author of Cache_Lite and Zend_Cache.
So, your last argument isn’t a good one :-)
filelocking is a good thing in some cases. But on NFS, I will turn off.
You are protected against cache corruption by read_control and write_control
But, IMHO, the problem is maybe you have to many cache files into a single directory. There is a specific option to deal with that.
Flock() was blocking even with very few cache files :/ I gave up on this and turned file locking off on the server. This finally prompted me to rewrite a part of Minify so this could be an easy user option as well.