I have enabled APC in php.ini, and looking at phpinfo(), it all seems ok.
I also have apc.enable_cli=1 directive in php.ini.
I've stored several keys that start with raw_ prefix and they get stored (apc_store() returns true, apc_fetch() returns the value for that key.
All ok so far.
So I wanted to use APCIterator to fetch all keys that start with raw_, using this statement:
$iterator = new APCIterator("user", '/^raw_\.*/');
A key looks like this:
raw_2014-04-17 12:19:00_0.68206200 1397726355534f9c93a68649.18047787158329
It seems that if I print_r($iterator) or iterate it using foreach(), it is empty.
Any ideas what can be wrong?
Thank you!
Actually the problem was this: How can I get PHP to use the same APC cache when invoked on the CLI and the web?
I used CLI mode to fetch from APC and used store() via HTTP request. APC does not share data between Apache and CLI
Related
On my apache instance it is setting an env variable APP_ENV=development. I am trying to change this dynamically on my PHP side (in the instance of firing up test suite) like so:
putenv('APP_ENV=testing')
var_dump(getenv('APP_ENV')); // still returns development
I have tried:
Starting php in safe mode in php.ini
Setting safe_mode_allowed_env_vars = PHP_ APP_ in php.ini
Update:
I am using PHP version 5.4.16 and notice that safe mode has been deprecated. I'm not sure if this means putenv will even work for overwriting or even unsetting existing envs?
You are using an Apache variable, so, you should use apache_setenv() and apache_getenv()
apache_setenv('APP_ENV', 'testing');
To recover it use:
apache_getenv('APP_ENV');
The docs say the list needs to be comma delimited.
try PHP_,APP_
I'm currently having troubles about local deployment of my web service api. I'm using memcached with PHP Memcache extension. Here's the following behaviour;
I have a login function that firstly checks whether the user information is on memory with following code;
$cache = Memcacher::get_instance()->load( 'user.' . $email);
if the cache exists, then it will return the variable $cache to be true.
if the cache doesn't exist, then I'm saving it to the memory with following code;
$cache = Memcacher::get_instance()->save( 'user.' . $login['value']['email'], $login);
the parameter $login is an associative array that holds user info.
After saving it to the memory, I try to re-login. However, it doesn't hold the info before I save to memcached server 3-4 times.
After 3-4 login, I get the login information from cache successfully.
Can anyone explain me that strange behaviour ? Is there any memcached configuration variable to prevent this ?
NOTE : I'm flushing the memory with restarting memcached with sudo service memcached restart
on Ubuntu
NOTE : Memcacher is a custom module that uses PHP Memcache extension's set() and get() function
NOTE : Here's the source code of Memcacher
You are concatenating an array with a string. At points, it might not be true that $login is an array, therefore you will start receiving the information you have because the concatenation will work. But if it is an array, you will not be able to save the key in memcache. You will receive a notice, which i guess you ignore.
I inherited an XP machine with xitami/pro server running on it and installed PHP 5.2.17 because I thought I might need the VC6 version.
PHP works and the phpinfo shows as it should. When I do www.domain.com/test.php?x=y&z=test the $_GET is not being populated.
The $_REQUEST variable is not being populated either. If I post it in a form and post it, the $_POST is empty as is the $_REQUEST.
If I loop through the $_SERVER variables and display them on a get, the QUERY_STRING is populated with the get variables.
When I do a print_r on any of the variables, it is empty. I get: Array ( ) 1
I then upgraded to PHP 5.4 and the same thing.
What is the problem? I am at a loss and don't know what else to try.
I would suspect this problem arises when the server is configured wrong. Especially when the wrong SAPI is used (for example, I'm pretty sure $_GET/$_POST are not available when using the PHP CLI.
To see if this causes your issue, create a new php file, and insert the following
<?php
echo php_sapi_name();
?>
In case this returns CLI I'm pretty sure that causes your issues. Solve it by configuring your server to use the correct SAPI.
TL;DR:
I assume you're using C:\php\php.exe as your PHP interpreter. Try C:\php\php-cgi.exe instead.
I've recently started using APC cache on our servers. One of the most important parts of our product is a CLI (Cron/scheduled) process, whose performance is critical. Typically the batchjob consists of running some 16-32 processes in parallel for about an hour (they "restart" every few minutes).
By default, using APC cache in CLI is a waste of time due to the opcode cache not being retained between individual calls. But APC also contains apc_bin_dumpfile() and apc_load_dumpfile() functions.
I was thinking these two function might be used to make APC efficient in CLI mode by having it all compiled sometime outside the batchjob, stored in a single dumpfile and having the individual processes load the dumpfile.
Does anybody have any experience with such a scenario or can you give good reasons why it will or will not work? If any significant gains could reasonably be had, either in memory use or performance? What pitfalls are lurking in the shadows?
Disclaimer: As awesome as APC is when it works in CLI, and it is awesome, it can equally be as frustrating. Use with a healthy load of patience, be thorough, step away from the problem if you're spinning, keep in mind you are working with cache that is why it seems like its doing nothing, it is actually doing nothing. Delete dump file, start with just the basics, if that doesn't work forget it try a new machine, new OS, if it is working make a copy, piece by piece expand functionality - there are loads of things that won't work, if it is working commit or make a copy, add another piece and test again, for sanity-check recheck the copies that were working before, cliches or not; if at first you don't succeed try try again, you can't keep doing the same thing expecting new results.
Ready? This is what you've been waiting for:
Enable apc for cli
apc.enable-cli=1
it is not ideal to create, populate and destroy the APC cache on every CLI request
- previous answer by unknown poster since removed.
You're absolutely right that sucks, lets fix it shall we?
If you try and use APC under CLI and it is not enabled you will get warnings.
something like:
PHP Warning: apc_bin_loadfile(): APC is not enabled,
apc_bin_loadfile not available.
PHP Warning: apc_bin_dumpfile(): APC is not enabled,
apc_bin_dumpfile not available.
Warning: I suggest you don't enable cli in php.ini, it is not worth the frustration, you are going to forget you did it and have numerous other headaches with other scripts, trust me its not worth it, use a launcher script instead. (see below)
apc_loadfile and apc_dumpfile in cli
As per the comment by mightye php we need to disable apc.stat or you will get a warnings
something like:
PHP Warning: apc_bin_dumpfile(): Excluding some files from apc_bin_dump[file].
Cached files must be included using full path with apc.stat=0.
launcher script - php-apc.sh
We will use this script to launch our apc enabled scripts (ex. ./php-apc.sh apc-cli.php) instead of changing the properties in php.ini directly.
#/bin/sh
php -d apc.enable_cli=1 -d apc.stat=0 $1
Ready for the basic functionality? Sure you are =)
basic APC persisted - apc-cli.php
<?php
/** check if dump file exists, you don't want to use file_exists */
if (false !== $dump_file = stream_resolve_include_path('apc.dump'))
/** so where were we lets have a look see shall we */
if (false !== apc_bin_loadfile($dump_file))
/** fetch what was stored last run just for fun */
if (false !== $value = apc_fetch('my.awesome.apc.store'))
echo "$value from apc\n";
/** store what gets fetched the next run just for fun */
apc_store('my.awesome.apc.store', 'awesome in cli');
/** what a shlep lets not do that all over again shall we */
apc_bin_dumpfile(array(),null,'apc.dump');
Notice: Why not use file_exists? Because file_exists == stat you see and we want to reap the reward that is apc.stat=0 so; work within the include path; use absolute and not relative paths - as returned by stream_resolve_include_path(); avoid include_once, require_once use the non *_once counterparts; check your stat usage, when not using APC(Muchos important senor), with the help of a StreamWrapper echo for calls to method url_stat; Oops: Fatal scope over-run error! aborting notice thread. see url_stat
message: Error caused by StreamWrapper outside the scope of this discussion.
The smoke test
Using the launcher execute the basic script
./php-apc.sh apc-cli.php
A whole bunch of nothing happened that's what we want right, why else do you want to use cache? If it did output anything then it didn't work, sorry.
There should be a dump file called apc.dump see if you can find it? If you can't find it then it didn't work, sorry.
Good we have the dump file there were no errors lets run it again.
./php-apc.sh apc-cli.php
What you want to see:
awesome in cli from apc
Success! =)
There are few in PHP as satisfying as a working APC implementation.
nJoy!
I would definitely not use it in the CLI as when you restart it, it's almost as if it was never running in the first place!
The better way of using APC is to have it running on the webserver itself all the time, this way with it being active it will actually do what it's supposed to do!
I tryed with curl and APC.it works
use these commands in CLI
curl --data "param1=value2" http://testsite.com/test.php
so it will post data to test.php and you writes the code in it.
I have a form which sends data with the POST method, about 3000 array keys to be inserted in MySQL like this:
client_add[]=1
client_add[]=3
client_add[]=47
...
The problem is on my localhost on the development server works just fine. On production I only get about 1000 rows, on the localhot it seems to get lost, we confronted the php.ini files and the development server has everything set to more memory than my localhost.
I've run out of ideas.
The size of the post body will be somewhere around 50kb, which is ok as long as the server and/or PHP doesn't enforce a limit. It seems like your production environment enforces such a limit. You should check the entire webserver configuration, and if that is identical as well, compare compile-time defaults. Maybe the phpinfo() call shows more on the actual limits.
PHP has an ini setting which dictates the size of your POST request, you can probably find it in your ini under the name of post_max_size.
Also, if you've got the Suhosin patch installed it will enforce a limit on the number of POST variables you can submit on each request. I think this is around 2000 by default.