Performance improvements in Drupal with WINCACHE user cache

Now that WINCACHE 1.1 Beta is released and it has support for user cache, you can enhance Drupal’s performance by integrating WINCACHE user cache. For this you will need to have two things already setup:

Once you have above setup ready, integrating WINCACHE user cache is really easy. I will assume that you have copied CacheRouter extension in the ‘modules’ folder of Drupal installation. This means you should have added below lines in your file named settings.php inside folder sites\default:

$conf['cache_inc'] = './modules/cacherouter/cacherouter.inc';
 
$conf['cacherouter'] = array(
 
  'default' => array(
 
    'engine' => 'wincache',
 
    'servers' => array(),
 
    'shared' => TRUE,
 
    'prefix' => '',
 
    'path' => 'sites/default/files/filecache',
 
    'static' => FALSE,
 
    'fast_cache' => TRUE,
 
  ),
 
);

Now let’s move to next step. Please save the file named wincache.php_.txt from link http://drupal.org/node/743028 as wincache.php file to folder modules\cacherouter\engines.

Restart your server and you are done.

In order to verify that WINCACAHE is storing values in user cache, hit the homepage of your Drupal installation. Now open WINCACHE.PHP file which ships with the installation and click on tab named “User and Session Cache”. It should look something like below:

image

As of writing this blog, a bug in CacheRouter (daily builds) prevents any caching functionality to work. The bug has been logged at http://drupal.org/node/743238.

In order to make it work with older versions of CacheRouter build like 7.x-1.0-beta1, 6.x-1.0-rc1 or 5.x-1.0-beta9 the attached file at http://drupal.org/node/743028 should be changed. The change is very simple in itself. Just replace the first line excluding comment or line 7 including comment which is:

class wincacheCacheRouterEngine extends CacheRouterEngine {

by the below line:

class wincacheCache extends Cache {

We would like to thank ‘Tauno Hogue’ for providing with the WINCACHE equivalent of cache file.

In this blog post you learnt how to leverage WINCACHE user cache functionality to enhance performance of Drupal. Hopefully this will be useful to you in running Drupal faster on WINDOWS. Happy caching and till we meet again ‘Good Bye’.

Thanks,

Don.

PS: This works only with WINCACHE version 1.1.0 and higher. So please make sure that you are not running any lower versions of WINCACHE like 1.0.0 or 1.0.1.

27 Comments

  • I am testing this out, I have it working on a development site I soon hope to make live.
    I am having one minor problem possibly, I'm getting a lot of errors in my PHP log about line 208.

    [02-Apr-2010 13:44:10] PHP Fatal error: Maximum execution time of 240 seconds exceeded in #### on line 208

    Is this anything to be concerned about?

    I am running:
    Windows 2008 IIS7 x86
    PHP 5.2.13
    Wincache 1.1 Beta
    Drupal 6.16
    Cacherouter 6.x-1.x-dev

  • Hi,

    Are the errors appearing only after you enable WINCACHE?If yes, there is something wrong somewhere. Look at what the line is trying to do.

    WINCACHE.php is the best bet to see if user cache is happening or not.

    Thanks,
    Don.

  • yes this error only happens after wincache is enabled, its line 208 of wincache.php

    I am alsoe getting the following error which is in the same lock() function in the wincache.php

    warning: wincache_ucache_add() [function.wincache-ucache-add]: function called with a key which already exists in \sites\all\modules\contrib\cacherouter\engines\wincache.php on line 205.

    You can see my wincache on a live site working here http://www.wastedtalent.ca/wincache.php

  • warning: wincache_ucache_add() [function.wincache-ucache-add]: function called with a key which already exists in \sites\all\modules\contrib\cacherouter\engines\wincache.php on line 205.

    This means the key used to store data using function wincache_ucache_add() already exists. Use '@' at the beginning of the function. I mean @wincahce_ucache_add($this->lock, TRUE). This should stop the error/warning message in the log file. This is pretty normal as lock may already be present and in that case it will return false and also warning message.

    I am not sure why are you getting the other error:
    [02-Apr-2010 13:44:10] PHP Fatal error: Maximum execution time of 240 seconds exceeded in #### on line 208
    As per the code you should not get this. Look the code is:


    function lock() {
    // Lock once by trying to add lock file, if we can't get the lock, we will loop
    // for 3 seconds attempting to get lock. If we still can't get it at that point,
    // then we give up and return FALSE.
    if (wincache_ucache_add($this->lock, TRUE) === FALSE) {
    $time = time();
    while (wincache_ucache_add($this->lock, TRUE) === FALSE) {
    if (time() - $time >= 3) {
    return FALSE;
    }
    }
    }
    return TRUE;
    }
    This means the while loop should be tried only for 3 seconds. Beyong that time()-$time should be bigger than 3 seconds and the function should return FALSE. Not sure why is that happening.

  • I will try the @ to surpress the errors, but I'm not sure if that will fix the problems.

    My site will run fine for awhile then grind to a halt, when this happens and i manage to get a pageload in, I see hundreds and hundresds of the "wincache_ucache_add" warnings output to the screen. I've attached 2 screenshots of the "database logging" and a detail. Something odd to note, I clicked on the details for about 10 entries randomly, they all have "?fbc_channel=1" in the location

    http://i355.photobucket.com/albums/r469/canadaka_bucket/wincache_ucache_...
    http://i355.photobucket.com/albums/r469/canadaka_bucket/wincache_fbconne...

    So could it be some incompatability with the fbconnect module? if so why does it run fine for a period then die. Even if I add the @ to the function, something doens't seem right. Why is it checking several hundred cache keys and failing at them all on a single pageload.

  • You are right. You may have encountered a bug in WINCACHE. The photo link is broken. last night I tried reproducing this on my Drupal site but couldn't. I will see what this fbconnect is. If I am not able to repro I will put you through my developer and see if he can help getting the repro. My best guess is that wincache_ucache_add is getting into some kind of infinite loop and hence your site is tming out.

    Thanks,
    Don.

  • Ok, I debugged this further. Can you increase your user cache size. Please go to PHP.INI file and say wincache.ucachesize=16. Use wincache.php to ensure that size has been increases. Ans yes prepend an @ at the beginning of wincache_ucache_add function. I suspect that you are running out of user cache memory and so plenty of logs as well as time outs.

    Let me know if this helps.

    Thanks,
    Don.

  • Hmm thats annoying the comments cut off long URL's here I will shorten them.
    http://bit.ly/cHkNcl
    http://bit.ly/dprOTl

    I have memory to spare so i will set the user cache fairly high

    [WinCache]
    extension=php_wincache.dll
    wincache.ocachesize=256
    wincache.ucachesize=128

  • ok i'm trying it out again with the above settings. I've been using memcached the last few days to compare, it runs stable. But i think i'm running into caching problems, where logged in users will sometimes be given a cached page of another user or guest user. I guess that might be because i'm still running wincache globally with PHP.

    I presume running wincache with cacherouter so it uses the user cache, this fixes that problem?

  • We will need to know more about it. WINCACHE does store the file but it is based on full path. Users seeing each other page is something I have not heard of because of caching. Try disabling file cache by writing wincache.fcenabled=0 in your php.ini file and see if this fixes your problem. If yes, we would like to know more so that we can fix it.

    WINCACHE with cacherouter just stores variables/results into wincache user cache, nothing else.

  • But globally php_wincache.dll is doing its normal opcode caching, which I think is the source of the users seeing cached pages they shouldn't. Which is completely seperate from drupal or the wincache engine for cacherouter.

    My settings & stats are here http://www.wastedtalent.ca/wincache.php

    I can't actualy reproduce the problem, so its hard to troubleshoot. I just get users emailing and messaging me that it was happening to them.

  • Apply the wincache settings, I told you. I mean wincache.fcenabled=0 in your php.ini file. And see if this is solving your problem. We will definitely need some more information if we have to fix it. There is no magic we can do to reproduce it in-house.

    BTW, your user cache is working pretty well. Enjoy!!

  • Ok i just logged out of the site, I was logged in as admin. The homepage loaded correctly as a guest would see, but I then went to another comic page and it loaded a page with my logged in as admin again. I did a ctrl-F5 and it re-loaded as the correct page as a guest would see.

    I will apply that setting to wincache and try to reproduce the above.

  • WOw there is definatly a major problem, I might have to stop using wincache... I really don't want to though.

    I set wincache.fcenabled=0 and restarted the application pool, and verified it was off using the wincache.php page.

    I think logged into my admin page, browsed toa few pages that were unlickyl to have been cached recently, then logged out and went to those same pages as a guest and they loaded as if I was still logged in as admin. Even refreshing the page didn't help. Only going to a page I know i didnt visit while I was logged in would I load a page as a guest.

  • Sorry for posting so much, i should have waiting before posting 3 times.

    I have setup a local dev version of IIS7.5 and the site on my desktop and I was able to reproduce the problem there. SO I then tried disabling authcache and boost. After doing that the problem seemed to be gone, so i think tried enabling just authcache and the problem was still gone. I then enabled boost and the problem was back.

    So I guess boost is creating the static page caches from pageloads made by me as admin, then presenting them to guest users. I thought that boost only generated the cache pages from a guest request and only used the cached pages for guest requests.

    Its weird though, when I logout and view a page that loads a cached version as if I was logged in, when i view the source it doesn't have the "<!-- Page cached by Boost..." tag at the very bottom of the HTML like normal. So i'm not sure what is presenting this cached page, must be wincache.


    Until a solution is found I guess I will have to choose either to use wincache or boost. Boost really makes pageloads for guests users fast, I think probably faster than wincache can, since it serves fully rendered html pages.

  • I am so confused as to what's happening, but i think it's not because of wincache. Even with wincache not loaded in php.ini and not used as the cacherouter engine, I can reproduce the wrong pages being loaded for guests problem.

    But I'm noticing some other strange things with it. I have boost enabled again and I had thousands of boost cached files in the /cache folder, so i wiped it clean. I wanted to check if anything was every generated while browsing the site as admin or any authenticated user. Nothing is, which is what should be the case. But still if I view some random pages then logout and view those same pages as a guest i am loaded a cached page showing me as logged in with the admin menu at the top. But the strange thing is I can try viewing the same page in a different browser (chrome vs firefox) and then the page loads fine.

    If i clear the browsers cache then refresh a page that is loading as if I were an admin, then it reloads to what it should be. Something weird is going on.

    here are the headers responses for 3 different pageload types:

    ###### page loading as if I was logged in as admin (as guest) #######

    Cache-Control: store, no-cache, must-revalidate,post-check=0, pre-check=0
    Content-Type: text/html; charset=utf-8
    Expires: Sun, 19 Nov 1978 05:00:00 GMT
    Last-Modified: Thu, 08 Apr 2010 07:46:13 GMT
    Server: Microsoft-IIS/7.0
    X-Powered-By: PHP/5.2.13
    Date: Thu, 08 Apr 2010 08:12:39 GMT
    Content-Length: 61516
    Accept-Ranges: bytes

    200 OK





    ###### NON BOOST CACHED PAGE (as guest) #######

    Content-Type: text/html
    Last-Modified: Thu, 08 Apr 2010 08:12:47 GMT
    Accept-Ranges: bytes
    Etag: "0f51346f3d6ca1:0"
    Server: Microsoft-IIS/7.0
    Date: Thu, 08 Apr 2010 08:12:52 GMT
    Content-Length: 16058

    200 OK




    ###### BOOST CACHED PAGE (as guest) #######

    Content-Type: text/html
    Content-Encoding: gzip
    Last-Modified: Thu, 08 Apr 2010 08:12:45 GMT
    Accept-Ranges: bytes
    Etag: "80bc9c44f3d6ca1:0"
    Vary: Accept-Encoding
    Server: Microsoft-IIS/7.0
    Date: Thu, 08 Apr 2010 08:13:02 GMT
    Content-Length: 5102

    200 OK


    So after further testing it seems the problem is likely related to the "authcache" module and not the "boost" module. If i disable the authcache module but keep boost enabled, the problem is gone.

    So this is most liky an issue I need to bring up with the authcache authors, at this point I don't think this specific problem is related to wincache.

  • Thanks for the information. Glad to know that WINCACHE is working fine. Let me know if your user cache (getting lot of warning) got fixed too after increasing the user cache memory.

  • Yes it appears that either giving the user cached more memory ore surpressing the errors with @ has fixed that problem. I hanv't had the site crawl to s standstill like it was when those errors were getting spewed out.

    I think I finally might have fixed my problem with users getting the wront cached pages, turns out its not any of the caching modules, but a core drupal problem. I applied the fix mention in this topic http://drupal.org/node/197786

  • Yes increasing memory has fixed it. When I loooked at your wincache.php some days back, one thing that caught my attention was that your user cache memory was full. I simulated a similar environment here and I also started getting 1000 of error from wincache_ucache_add. Prending @ is a good solution as wincache_ucache_add will fail if entry with the same key is already there. I will work with drupal developer to get this fixed.

    Thanks for your time and effort.

  • When my site is stalling I am unable to load any PHP page, including the wincache.php to check to see if the wincache memory is full. Is there another way I can check the wincache memory usage?

  • Unfortunately if PHP is down or FastCGI is not working properly there is no way to check this. This just means that none of your PHP pages will load and it is a big problem. I am for sure recycling the application pool will get rid of the problem but that's not the right solution. As discussed in forum try reducing things more. Also re-introduce things otherwise you will not know if combination is creating problem.

    Thanks,
    Don.

  • Yah its weird, doing a recycle of the application pool doens't unstall things, it also doens't seem to wipe the wincache memory. I have to do a complete stop of the app pool, wait a few seconds than start again.

    But of course doing this dumps the wincache memory so i can't check if it was full or not.

    There isn't any kind of log for wincache is there?

  • You can set wincache.debuglevel=301 and run DbgView. Ensure that Under capture menu 'Capture Global Win32' is checked. This will force WINCACHE to start writing to DbgView. You can download DbgView from http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx.

  • It seems that wincache is the source of my problems, disabled it and the site has run fine for 3 days now. Maybe should continue discussion here? http://forums.iis.net/t/1166568.aspx

  • Yes, we can continue the discussion in the forum.

  • Anonymous comments are disabled here, so please login and comment.

    Don.

  • The same code should work, though we are working on a modified version which will use wincache_lock/wincache_unlock. But the old code should work too. Are you facing any problem?

    Thanks,
    Don.

Comments have been disabled for this content.