WinCache user cache entries not sticking around after a few minutes RRS feed

  • Question

  • User-1726608675 posted

    Regardless of any wincache.ttlmax I set, my user cache entries are disappearing after roughly ten minutes.  I suspect this might be a result of FastCGI killing the php-cgi.exe process.  If this is the case, is there any way I can prevent this short of sending a keep-alive HTTP request every few minutes?  Also, if FastCGI is creating multiple php-cgi.exe instances, are user cache entries shared between all of them?  How about command line php?

    I am running IIS6 w/ the FastCGI add-on, PHP 5.3.3, WinCache  1.1.0630.0.

    Here is some background on what I am attempting to do and I realize this is not really what WinCache was intended for:

    I have a requirement to build a logging mechanism to record various bits of info from each PHP request.  This will be used so we can better understand how folks are using our app.

    We don’t mind losing some log entries here and there but it is a requirement that we minimize any detriment to server capacity and page response time.  In addition, if the logging mechanism should fail we want things to continue running with no user impact.  I.e. if the logging DB box fails users won’t have to sit there and wait for the timeout to pass, etc.

    I have tested spawning background DB inserts, local ActiveMQ, Memcached, and SQLite.  Nothing touches the WinCache user functions for writing a simple text log entry with 6 small fields of data.  Memcached does pretty well if I use Memcache::pconnect for making the connection but still is enough of a percentage behind WinCache that I would like to make it plan B.  WinCache is just too awesome. ;)

    My intent was to put entries into WinCache with one or more counters to keep track of what entries are there and such.  At some interval, say 20 minutes, a schedule task/cron job/service would kick off on a separate box and hit a PHP page that will return a block of log entries from WinCache that could be inserted/imported into the persistent DB.

    I have implemented something like this before on a LAMP stack with eaccelerator and was hoping to do the same again on Windows.

    here is my test function:

    function logRequest($result){
        $entry = array('time_stamp'=>time(), 'ip_address'=>$_SERVER['REMOTE_ADDR'], 'user_id'=>'1', 'action_param'=>$_GET['action'], 'parameters'=>$_SERVER['QUERY_STRING'], 'result'=>$result);
        $table = 'log';
        $table_idx = $table . '_idx';
            wincache_ucache_set($table_idx, 1);
            $qIdx = 1;
        } else {
            $qIdx = wincache_ucache_inc($table . '_idx');
        wincache_ucache_set($table . '_' . $qIdx, $entry);




    Tuesday, October 19, 2010 2:00 PM

All replies

  • User-1726608675 posted

    I think I found the answers to all my questions and I am posting them here for anyone else that has the same questions.

    After I applied a load to my test server I let it sit idle with no traffic hitting it.  FastCGI kills instances after they are idle for a certain amount of time.  Any user cache entries associated with that instance are apparently destroyed when that instance dies.  There is an IdleTimeout setting in the fcgiext.ini file that can be increased to mitigate this issue.

    User cache entries do seem to be shared between instances but entries associated with a particular instance are destroyed.  Per another post on this board it sounds like PHP CLI and HTTP instances will not see each others user cache entries.

    There is an InstanceMaxRequests setting in the fcgiexe.ini that dictates how may requests an instance may handle before it is destroyed and replaced.  When the number of requests to a PHP FastCGI instance hits the InstanceMaxRequests, the instance is recycled and all user cache entries are lost.  I could make the InstanceMaxRequests number really high but not without risks of memory leaks over the much longer instance lifespan.  Unfortunately this means WinCache will not work for my logging mechanism.


    Wednesday, October 20, 2010 10:17 AM