Re: [PHP] [Case Closed - Idiot Found Behind Keyboard] Re: [PHP] APC - problems with CLI & odd return values from apc_clear_cache()

[Jochem Maas]

Ray Hauge wrote:
> On Saturday 29 July 2006 05:47, Jochem Maas wrote:
>> Jon Anderson wrote:
>>> Just replying to the list on this one 'cause I'm pretty sure you're on
>>> it. :-)
>>>
>>> AFAIK, with many caches the web server cache and CLI caches are
>>> exclusive to each process. The APC manual seems to suggest that the CLI
>>> cache is not connected to the web server cache:
>>>
>>> From: http://ca.php.net/manual/en/ref.apc.php
>>>
>>> apc.enable_cli *integer*
>>> 
>>>
>>>Mostly for testing and debugging. Setting this enables APC for the
>>>CLI version of PHP. Normally you wouldn't want to create, populate
>>>and tear down the APC cache on every CLI request, but for various
>>>test scenarios it is handy to be able to enable APC for the CLI
>>>version of APC easily.
>> thanks, you are right - what I thought had been working all this time had
>> not, or atleast the code did work but it was clearing the cache belonging
>> to the CLI, which was a pointless act!
>>
>> I'm an idiot.
>>
>> but wanting to clear the webservers APC cache from a cmdline script doesn't
>> seem like such a stupid thing to want to do. but there is no nice way of
>> doing it; so now I do this at the end of my cmdline script instead:
>>
>> exec('apachectl -k graceful');
>>
>> which sucks in so many ways it hurts  but it does clear the APC cache
> 
> You could create a script that basically just does apc_clear_cache() et all. 
> and call it from lynx, curl, wget, etc. and throw that into a cron job.  That 
> would technically get you to call the script from the cli, but it should 
> clear the webserver cache. 

I thought about that but it means dealing with my own login system and apart 
from
having to figure that out, it's seems like a kludge ... in the end
hitting apache with a 'graceful' was alot quicker to get running ;-)

> 
> Ray
> 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] [Case Closed - Idiot Found Behind Keyboard] Re: [PHP] APC - problems with CLI & odd return values from apc_clear_cache()

[Ray Hauge]

On Saturday 29 July 2006 05:47, Jochem Maas wrote:
> Jon Anderson wrote:
> > Just replying to the list on this one 'cause I'm pretty sure you're on
> > it. :-)
> >
> > AFAIK, with many caches the web server cache and CLI caches are
> > exclusive to each process. The APC manual seems to suggest that the CLI
> > cache is not connected to the web server cache:
> >
> > From: http://ca.php.net/manual/en/ref.apc.php
> >
> > apc.enable_cli *integer*
> > 
> >
> >Mostly for testing and debugging. Setting this enables APC for the
> >CLI version of PHP. Normally you wouldn't want to create, populate
> >and tear down the APC cache on every CLI request, but for various
> >test scenarios it is handy to be able to enable APC for the CLI
> >version of APC easily.
>
> thanks, you are right - what I thought had been working all this time had
> not, or atleast the code did work but it was clearing the cache belonging
> to the CLI, which was a pointless act!
>
> I'm an idiot.
>
> but wanting to clear the webservers APC cache from a cmdline script doesn't
> seem like such a stupid thing to want to do. but there is no nice way of
> doing it; so now I do this at the end of my cmdline script instead:
>
> exec('apachectl -k graceful');
>
> which sucks in so many ways it hurts  but it does clear the APC cache

You could create a script that basically just does apc_clear_cache() et all. 
and call it from lynx, curl, wget, etc. and throw that into a cron job.  That 
would technically get you to call the script from the cli, but it should 
clear the webserver cache. 

Ray

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] [Case Closed - Idiot Found Behind Keyboard] Re: [PHP] APC - problems with CLI & odd return values from apc_clear_cache()

[Jochem Maas]

Jon Anderson wrote:
> Just replying to the list on this one 'cause I'm pretty sure you're on
> it. :-)
> 
> AFAIK, with many caches the web server cache and CLI caches are
> exclusive to each process. The APC manual seems to suggest that the CLI
> cache is not connected to the web server cache:
> 
> From: http://ca.php.net/manual/en/ref.apc.php
> 
> apc.enable_cli *integer*
> 
> 
>Mostly for testing and debugging. Setting this enables APC for the
>CLI version of PHP. Normally you wouldn't want to create, populate
>and tear down the APC cache on every CLI request, but for various
>test scenarios it is handy to be able to enable APC for the CLI
>version of APC easily.

thanks, you are right - what I thought had been working all this time had not,
or atleast the code did work but it was clearing the cache belonging to the CLI,
which was a pointless act!

I'm an idiot.

but wanting to clear the webservers APC cache from a cmdline script doesn't seem
like such a stupid thing to want to do. but there is no nice way of doing it; 
so now
I do this at the end of my cmdline script instead:

exec('apachectl -k graceful');

which sucks in so many ways it hurts  but it does clear the APC cache :-/

> 
> 
> 
> jon
> 
> Jochem Maas wrote:
>> hi people,
>>
>> PHP version:5.1.1(last built: Dec 28 2005 16:03:22)
>> APC version: 3.8.10
>> Apache version:2.0.54(last built: Dec 29 2005 14:04:16)
>> OS:debian
>>
>> I have a script that runs via the cmdline, it's used to import/update
>> data
>> in a database, after the script is run the APC cache needs to be
>> cleared so that
>> that the new/updated data is visible on the website. to do this I call
>> a static
>> method of my cache management class which effectively performs the
>> following:
>>
>> apc_clear_cache();
>> apc_clear_cache("user");
>>
>> this used to work, but now it does not (atleast not on the cmdline;
>> calling the
>> above mentioned method via a webrequest still works). I have not
>> recently updated
>> php, apc or apache, neither have made any changes to the php.ini
>> configuration.
>> someone else may have updated the OS/system (and I can't rule out that .
>>
>> to test the problem I ran the following code at the cmdline:
>>
>> # php -r 'var_dump( ini_get("apc.enable_cli"),
>> apc_clear_cache(),
>> apc_clear_cache("user") );'
>>
>> this is the output I get:
>>
>> string(1) "1"
>> NULL
>> bool(true)
>>
>> so apc is enabled for the cli, cache clearance seems to work but when
>> I checking the output
>> of the apc.php file (shipped with the apc package) I see that nothing
>> has been cleared; performing
>> the same apc_clear_cache() calls (by way of pressing the buttons on
>> the page output by apc.php) via
>> the webserver module *does* clear the cache.
>>
>> it seems all of a sudden that the CLI and then apache SAPI are looking
>> at different caches -
>> running apc_cache_info() && apc_sma_info() on the commandline show
>> nothing in the cache whereas
>> viewing the stats produced by apc.php (via the webserver) shows plenty
>> of stuff in the cache (both
>> before and after running apc_cache_info() && apc_sma_info() on the
>> commandline)
>>
>> can anyone offer some help/idea/etc?
>>
>>
>> Another Thing:
>> ===
>>
>> although the manual states that apc_clear_cache() should always return
>> a boolean
>> calling it calling the function without any args *always* returns
>> NULL. can anyone say whether
>> this is a bug or a documentation problem?
>>
>>
>> My APC ini settings (as defined in a seperate apc.ini):
>> ===
>>
>>
>>
>> ; Enable APC  extension module
>> extension   = apc.so
>>
>> [APC]
>> apc.enabled = 1
>> apc.shm_segments= 2
>> apc.shm_size= 128
>> apc.optimization= 0
>> apc.num_files_hint  = 2000  ; ?
>> apc.ttl = 180
>> apc.gc_ttl  = 0
>> apc.slam_defense= 0
>> apc.file_update_protection  = 0 ; 1
>> apc.cache_by_default= 1
>> apc.enable_cli  = 1
>> apc.filters = -.*\.class\.php
>>
>> ;   +\.tpl\.php,+.*\.interface\.php,+.*\.funcs\.php
>> ;   +.*\.class\.php
>>
>> ;apc.max_file_size  = 8M
>> apc.user_entries_hint   = 0
>> apc.user_ttl= 0
>>
>> ; this fixes a bug that causes $_SERVER not to be defined on
>> 2nd/subsequent requests
>> auto_globals_jit= Off
>>
>>   
> 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, v