Re: [APC-DEV] Ideas for APC 3.0.15/16

In Nings and our setup developers can modify the fille in wich case it does need to be cached as its own entry when it gets updated in the cache.  

Sent via BlackBerry from T-Mobile

-----Original Message-----
From: Rasmus Lerdorf <[email protected]>

Date: Fri, 22 Jun 2007 00:25:33 
To:Brian Shire <[email protected]>
Cc:Gopal V <[email protected]>, [email protected]
Subject: Re: [APC-DEV] Ideas for APC 3.0.15/16


Why not just symlink them?  If they really are identical, why store them
in the filesystem twice?

-Rasmus

Brian Shire wrote:
> 
> Almost forgot another idea which originally comes from Ning.  They (and
> Facebook in dev) end up loading duplicates of the same php files because
> they have different paths.  It would also be nice to be able to identify
> duplicates and only cache one version.  (A little tricky, but would save
> a lot of memory in these cases).
> 
> -shire
> 
> On Jun 22, 2007, at 12:05 AM, Brian Shire wrote:
> 
>>
>> Hey Gopal,
>>
>> I'm currently working on a binary dump that will dump the entire user
>> cache and file cache (with filter options as well) into a binary file
>> which can then be reloaded into APC.  I have a nearly working copy
>> that's still a little buggy, so I'm re-factoring the code and should
>> be done fairly soon.  This should give you the ability to do your
>> second option, and possibly the first idea as well.  One limitation of
>> this is that it is binary, so it is not compatible between different
>> architectures ie: endianess/64-32-bit.
>>
>> The PHP API is currently:
>>
>> string data apc_bindump(array file_filter, array user_filter);
>> string data apc_bindump_file(string file, array file_filter, array
>> user_filter);
>> int apc_binload(string data);
>> int apc_binload_file(string file);
>>
>> The *_file can also except url's etc.  I believe I also added a way to
>> pass in a file descriptor as well.  Let me know if you have any
>> suggestions, perhaps a better name than "bindump" is in order but I
>> just haven't though up anything better yet.
>>
>>
>> The JSON mode for apc.php would be useful.  I currently use a much
>> simpler version to grab statistics from the apc_cache_info with the
>> limited flag set. Something built in to apc.php would be useful for a
>> number of things, possibly including getting stats from users
>> reporting bugs.
>>
>>
>> Some additional ideas I have or have partial code for:
>>
>> Least recently used algorithm for cleaning up the cache.
>> Multiple memory segment support, which would allow you to create two
>> segments with different configurations.
>>
>>
>> Do you have plans to rework some of the memory management?
>>
>> -shire
>>
>> On Jun 19, 2007, at 10:37 PM, Gopal V wrote:
>>
>>> Hi,
>>>
>>> I'm sort of playing around with a lot of ideas for apc 3.0.15,
>>> to be planned out slowly now and done in the 1st week of Jul.
>>>
>>> First up, how about a persistant APC user cache ? Something which
>>> dumps everything without a TTL into a serialized data dump
>>> on MSHUTDOWN and re-loads it in MINIT.
>>>
>>> Second, a way to compile a large number of files and throw them
>>> into cache in one go. sort of like apc_compile(), but in batch
>>> mode, without inserting them as and when they are compiled ?
>>> This in combination with the nostat mode should make it relatively
>>> easy to avoid cache slams.
>>>
>>> And then a trivial mod - have a JSON mode for apc.php and a
>>> quick cache health monitoring cron script. Basically checks
>>> for fragments, cache insert rate, expunge count.
>>>
>>> Just sort of a heads-up, so if anybody has any suggestions or
>>> caveats (especially about #2), shoot :)
>>>
>>> Cheers,
>>> Gopal
>>> -- 
>>> The difference between insanity and genius is measured by success
>>>
>>> -- 
>>> APC Development Mailing List (http://pecl.php.net/APC)
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>
>> -- 
>> APC Development Mailing List (http://pecl.php.net/APC)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>