PHP :: Request #57341 :: apc_store / apc

[2006-11-03 06:19 UTC] apc at tequilasolutions dot com

Description:
------------
I've been using apc_store to cache the results of complex queries, the cached values are valid until the database changes.   I always store the last update time and can retrieve it with get_last_modified_date()

Basically, I needed an apc_fetch($key,$udt) that only returns the data if the cached value is newer than the passed udt, otherwise dumps the cached value.

Reproduce code:
---------------
I've written some wrappers to provide the functionality, but some way to use apc_fetch conditionally depending on how old the cached value is would probably be a useful feature.

function apc_fetch_udt($key){
	global $no_sql_cache;
	if (isset($no_sql_cache) and $no_sql_cache) return;
	$g = apc_fetch($key);
	if ($g){
		list($udt,$val) = $g;
		if (get_last_modified_date()<$udt) {
			$val = unserialize($val);
			return $val; 
		} else {
			apc_delete($key);
		}
	}
}
function apc_store_udt($key,$g){
	global $no_sql_cache;
	if (isset($no_sql_cache) and $no_sql_cache) return;
	$udt = time();
	$g   = serialize($g);
	$apc = array($udt,$g);
	apc_store($key, $apc);
}


Expected result:
----------------
Just as an aside, I've been getting locking problems with my server going into deadlock using apc_store, I've tried using normal and semaphore locks and can't find much on the net about problems with apc_store apart from it perhaps has problems when storing arrays of thousands of items (which I am doing).

Any advise on programming practice to avoid deadlock when using apc_store would be appreciated.

Actual result:
--------------
Thanks

Steve

[2006-11-03 11:42 UTC] rasmus@php.net

I'd be surprised if it was a deadlock.  Anything in the logs?

When storing really large things, you start to hit lock contention pretty fast because I have to keep the lock in place while the data is copied out of shared memory.  That can really hurt performance and you may actually be better off caching large blobs like these somewhere else.  You'll have to experiment a bit to find the tipping point between size and performance.

[2006-11-03 12:16 UTC] rasmus@php.net

Sorry, got turned around there.  The lock only has to stay in place on cache inserts, so you'll hit lock contention if you are writing a lot of large blobs to the cache.

[2006-11-03 13:30 UTC] apc at tequilasolutions dot com

I am writing large? blobs to the cache, on average about 1Mb and this is accessed every page view, updated a lot on the first 100 or so hits then basically everything is cached, so if the server makes it past the first 30 minutes its usually ok.  I did have some success putting in a 5 second delay with a 'cache busy' flag that stopped lots of concurrent writes.   This also stopped fragmentation building.  But the symptoms are that the server basically locks up and you soon hit the max clients setting in apache as it spawns to service new clients.     In the logs you get lots of apc_store :.... deadlock avoided.

[2006-11-20 02:45 UTC] gopalv82 at yahoo dot com

I'm not quite sure about the locks for copy-to-shm part either. I don't see any locks in apc_cache_make_user_entry or in the enclosing blocks.

[2009-03-22 19:47 UTC] shire@php.net

There have been quite a few changes to locks, fragmentation, as well as preventing slams for user values.  Can we get a confirmation if this is still an issue on the latest CVS version?

[2009-05-05 14:47 UTC] shire@php.net

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.

Patches

Pull Requests

History

	php.net \| support \| documentation \| report a bug \| advanced search \| search howto \| statistics \| random bug \| login
go to bug id or search bugs for


Copyright © 2001-2024 The PHP Group All rights reserved.	Last updated: Fri Apr 19 17:01:30 2024 UTC