Opened 5 years ago

Closed 16 months ago

Last modified 3 weeks ago

#228 closed enhancement (fixed)

var cache doesn't work for php cli

Reported by: binBASH Owned by: moo
Priority: major Milestone: 3.1.0
Component: cacher Version: 3.0.3
Keywords: Cc: vitalif@…
Application: PHP Version: 5.5.0
Other Exts: SAPI: Others
Probability: Always Blocked By:
Blocking:

Description

I'm getting notices like this:
PHP Warning: xcache_isset(): xcache.var_size is either 0 or too small to enable var data caching in /srv/httpd/www.livenue.ch

Tried to adjust the var cache variables, but nothing changes.
In phpinfo it says xcache is enabled.

/opt/www/php/bin/php -v output shows:
PHP 5.3.0 (cli) (built: Sep 17 2009 15:25:16)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies

with XCache v1.3.0, Copyright (c) 2005-2009, by mOo

I dunno if the opcode cacher works as well.
When I run xcache admin scripts with php cli the tables are empty.

Tried to do a print_r($cacheinfos); but the array was empty.

uname -a output:
Linux stopovr 2.6.18-128.2.1.el5.028stab064.7 #1 SMP Wed Aug 26 15:47:17 MSD 2009 x86_64 x86_64 x86_64 GNU/Linux

Change History (18)

comment:1 Changed 5 years ago by moo

  • Resolution set to invalid
  • Status changed from new to closed

cli is not supported by XCache. admin scripts is run from httpserver/htdocs, not from cli

comment:2 Changed 4 years ago by laph

  • Resolution invalid deleted
  • Status changed from closed to reopened

Is there any chance to have a XCache Version that works with CLI in the (not so far) future?
We've a Zend Framework based project using Zend's Caching classes and would like to use XCache as (so-called) Backend.
But since we (have to) use our Stuff (Models) in CLI and FCGI Mode, we cannot use XCache as backend for Zend_Cache. Our app loads (and parses) dozends of XML-Files which are stored in Memcached after processing.
Well, I'd prefer XCache's Variable Cache over Memcached, since we use the Opcode Cacher anyway.

comment:3 Changed 4 years ago by JayPea

I'd vote for this, too.
It worked in xcache 1.2.2 and php 5.2.6
now in xcache 1.3.0 with php 5.3.2 it doesn't work anymore.

I need this for unit-testing (phpunit) my applications which use xcache as backend.
how would i test my xcache-backend without being able to use xcache on the CLI ?
i can't even use hudson build-server since it calles phpunit on the commandline.

comment:4 Changed 4 years ago by vitalif

  • Cc vitalif@… added

+1, I also confirm this issue.

Debian squeeze, php 5.3.2-2, xcache 1.3.0-7.

If cli is not supported by XCache, then XCache should print "CLI IS NOT SUPPORTED BY XCACHE", and should not give strange errors like "xcache.var_size is either 0 or too small to enable var data caching" despite of it is not really 0.

comment:5 Changed 4 years ago by moo

  • Resolution set to wontfix
  • Status changed from reopened to closed

error is not printed because most ppl tends to use same single php.ini for all sapi and most ppl don't know if and how they can separate php ini for each sapi

comment:6 Changed 3 years ago by georgyo

  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Version changed from 1.3.0 to 1.3.1

I am going to re-open this ticket because I think the message should not be printed at all for the CLI, or at least have some way to disable it, besides a blind 2>/dev/null.

Here is a case example of why. Ubuntu drops the xcache.ini into /etc/php5/conf.d/. This directory is sym-linked to apache2, cli, cgi, and fpm. This is desired case for almost everything. It allows you to easily load modules, and modified their config in the main php.ini file if necessary.

Mediawiki has a series of maintenance scripts, that are extremely useful for maintaining it. However, because of this error, all the scripts just spam the warning repeatedly; making the output of the script completely unreadable. Again, while it is possible to just redirect this errors, it is not ideal.

OK, so now I could recreate this conf.d folder for the cli, and now have to manage other wise universal config in two places for an error that is cryptic and incorrect. Also this error doesn't even affect the code in anyway, xcache just passes. Also, other xcache functions ARE working. So, to keep those enabled, I would need to rewrite all of mediawiki caching functions to test to see if both xcache and cli are being used.

Also, it should be noted again that error was introduced in 1.3.

At the very least the error should output something remotely correct for the CLI. It should also be downgraded from a WARNING message to an NOTICE message. A NOTICE is the more closely fits the error levels as described by: http://www.php.net/manual/en/errorfunc.constants.php

I hope you will at least consider some of this.

comment:7 Changed 3 years ago by ckujau

  • PHP Version changed from 5.3.0 to 5.3.3

+1 from me: if xcache is not available for php-cli, so be it. But listing it in phpinfo() and then complaining that xcache.var_size is set to 0 when used seems to be the wrong approach, IHMO.

$ php -r 'phpinfo();' | grep var.size
xcache.var_size => 256K => 256K

$ php -v
PHP 5.3.3-7+squeeze3 with Suhosin-Patch (cli) (built: Jun 28 2011 08:24:40)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies

with XCache v1.3.0, Copyright (c) 2005-2009, by mOo
with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins? GmbH

comment:8 Changed 3 years ago by moo

  • Milestone changed from 1.3.3 to undecided

it's up to end user to have separate ini for cli and other php sapi. simply slient everything in xcache+cli confuse some user trying to do it

comment:9 follow-up: Changed 2 years ago by moo

  • Resolution set to wontfix
  • Status changed from reopened to closed

XCache is useless with CLI. What you wanted is to share between different group of PHP which is unsupported by XCache. memcached come in handy for this case

comment:10 Changed 18 months ago by moo

  • Milestone changed from undecided to black hole

comment:11 in reply to: ↑ 9 Changed 16 months ago by 5lava

  • PHP Version changed from 5.3.3 to 5.5.0
  • Priority changed from critical to major
  • Resolution wontfix deleted
  • Status changed from closed to new
  • Type changed from defect to enhancement
  • Version changed from 1.3.1 to 3.0.3

Replying to moo:

XCache is useless with CLI. What you wanted is to share between different group of PHP which is unsupported by XCache. memcached come in handy for this case

I'd suggest to bring the question back from ashes.
libevent, libev, libeio, ... There are more and more "low-level" pecl-extensions for high-performance PHP backend development are available around. Daemons, daemons, cli rocks! Even sendmsg/recvmsg were finally added in php5.5 :)
Typical situation: parent process forks a number of children that handle the actual load. They all can have shared memory, and that's where XCache variable storage could fit perfectly.
APC is no longer maintained, variable storage was dropped from OPCache since php5.5, memcached are other sockets-based solutions are way slower than shared memory. https://github.com/krakjoe/apcu is the solution for me, it works fine on cli. I wish XCache to compete!

comment:12 follow-up: Changed 16 months ago by moo

try "export XCACHE_TEST=1" before running your PHP+XCache, is that enough for you?

comment:13 in reply to: ↑ 12 Changed 16 months ago by 5lava

It works, thank you so much!

is that enough for you?

Trac doesn't seem to have a feature "vote for bug", otherwise I'd vote for 1) atomic multiple get/set, and 2) check-and-set ("cas", update if exists). Thanks again.

comment:14 Changed 16 months ago by moo

  • Resolution set to fixed
  • Status changed from new to closed

In 1341:

cacher: fixes #228, enable var caching for cli

comment:15 Changed 16 months ago by moo

  • Milestone changed from black hole to 3.1.0

comment:16 Changed 16 months ago by kenorb

Related: #317

comment:17 Changed 3 weeks ago by cbichis

Hello,

I think the #228 fix lacks some more details:

  1. Is the var cache when managed under CLI is working shared with the var cache managed under http ?
  1. Is the var cache managed under 2 diff CLI scripts working shared ?

I tested both #1 and #2 on 3.1 and none is not working.

Example:

  1. I see in XCache admin multiple vars added through http. But under CLI I dont haccess to them (simply trying to get these variables is producing NULL return)
  1. I am trying to populate from one CLI php script a "demo" variable. Trying to get that variable from other PHP script it doesnt seems to work, I am getting NULL.

So I am confused related to functionality for "var caching for cli".

comment:18 Changed 3 weeks ago by moo

It fixes to allow cli that fork itself, not for different set of instances PHP cli

Note: See TracTickets for help on using tickets.