php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #57341 apc_store / apc_fetch with dates
Submitted: 2006-11-03 06:19 UTC Modified: 2009-05-05 14:47 UTC
From: apc at tequilasolutions dot com Assigned:
Status: No Feedback Package: APC (PECL)
PHP Version: Irrelevant OS: FC4
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: apc at tequilasolutions dot com
New email:
PHP Version: OS:

 

 [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

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Dec 26 16:01:31 2024 UTC