1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

XCache 3.0.0

Discussion in 'General PHP and MySQL Discussions' started by Brent W, Nov 6, 2012.

  1. Brent W

    Brent W Well-Known Member

    Who all is using the latest version? I am still using 5.3.18. I have it up and running but I don't seem to be able to find the admin area in the package?

    Per documentation here: http://xcache.lighttpd.net/wiki/InstallAdministration

    That folder does not exist within the 3.0.0 package. What am I missing
  2. digitalpoint

    digitalpoint Well-Known Member

    I have it running on one of my dev machine and it *seems* to be running fine... I actually thought it was a final version, but it's tagged as dev when you compile it.

    PHP 5.3.18 (cli) (built: Oct 22 2012 01:14:46) 
    Copyright (c) 1997-2012 The PHP Group
    Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
        with XCache v3.0.0-dev, Copyright (c) 2005-2012, by mOo
        with XCache Cacher v3.0.0-dev, Copyright (c) 2005-2012, by mOo
    The older admin seems to work fine (mostly)... it throws a few Notices on the "List PHP" page, but it still *works*...
  3. Brent W

    Brent W Well-Known Member

  4. digitalpoint

    digitalpoint Well-Known Member

    Oh yeah... that does work way better. :)
  5. Shamil

    Shamil Well-Known Member

    When I installed it earlier, it didn't come up as -dev, that said, ionCube promptly broke - I'm currently on 3.0.1-dev, 1178.

    I installed the stack from Floren's Axivo repo, which gave me APC 3.1.13 (beta) :: causing me about 15 hours of pain and countless questions on stackoverflow. My database class in my application was not always available to methods in my session manager, causing session failures in my application. What a pain that was.
  6. AdamD

    AdamD Well-Known Member

    Working aok here on a Cpanel/Whm server. (also running NGinxCP and Apache in FCGI mode)
  7. digitalpoint

    digitalpoint Well-Known Member

    I think I must have got the "final" 3.0.0 version too fast or something... it said the download was the final version, but compiled as 3.0.0-dev... re-downloading/compiling it doesn't show the -dev any more.

    I blame my XF admin page for reminding me to update to new versions of stuff too often. lol

  8. p4guru

    p4guru Well-Known Member

    haha i know what ya mean

    MySQL -> 5.5.28
    Memcached -> 1.4.15
    Memcache -> 3.0.7
  9. digitalpoint

    digitalpoint Well-Known Member

    Yeah... I have problems with the 3.x branch of memcache (specifically it segfaults if you try to get extended stats with it): https://bugs.php.net/bug.php?id=59626 And Memcached 1.4.15 will run for about 48 hours for me and then the daemon just disappears for no reason at all. Reverting back to 1.4.5 (the version I was using before I tried to upgrade) made it 100% stable again.

    My MySQL is out of date, but it's not that easy to update MySQL without taking the site down briefly. And Elastic Search, I'm more waiting for 0.20.0 before I bother. :)
  10. Deebs

    Deebs Well-Known Member

    Interesting, I am running memcached 1.4.15 with around 1500 requests/sec and have not had one issue as of yet. Do you have any logs or it simply just stops?
  11. digitalpoint

    digitalpoint Well-Known Member

    It simply stops... no crash or anything else. And always after about 48 hours. I restarted it after it happened the first time just thinking maybe it was some weird fluke (even though I've never had memcached crash ever)... ran fine for about 48 hours, and then it just went away again. At that point, I just reverted, and it's back to being fine.

    Will try upgrading again when 1.4.16 comes out, but clearly my servers didn't like 1.4.15 (wasn't just one server either... I run 4 memcached servers... same deal on all of them).
  12. Deebs

    Deebs Well-Known Member

    That is weird, maybe it is the new threading model. How many requests? I am running under Centos/Redhat 6.3.
  13. digitalpoint

    digitalpoint Well-Known Member

    I'm running OpenSUSE 11.4 which uses the 2.6.37 Linux kernel, RedHat 6.3 I believe uses the 2.6.32 kernel (not that it would really matter).

    Our traffic to memcached is not anywhere remotely close to the number of requests memcached struggles to handle. Around 5,000/sec (when you include the increment hits we are doing). I've load tested our setup and it can handle many millions per second.

    I've never had any problem with memcached over the years... it's always been fine and I've never ONCE had it crash in the years I've been using it. Which is why I was surprised to see 1.4.15 just "go away" after ~48 hours.... twice. :)
  14. p4guru

    p4guru Well-Known Member

    weird about memcached, wonder if it's distro related ?

    no problems I've seen on CentOS 6.x 64bit with (source compiled) memcached 1.4.15 + memcache 3.07 pushing 33,000 memcached hits/second. Using PHP 5.3.18 or 5.3.19.

    i do remember having problems with memcache 3.0.6 and 3.0.7 with earlier PHP (php-fpm) versions, so could be your issue ? I know PHP 5.3.18 and 5.3.19 fixed alot of segfault issues related to PHP-FPM.

    maybe xcache conflicts ? i've only briefly tested xcache 3.x and i mainly use APC 3.1.1x series

    just started playing around with twitter's version of memcached, twemcache as well https://github.com/twitter/twemcache
  15. digitalpoint

    digitalpoint Well-Known Member

    Doubt it's XCache since memcached is what pooped out, not memcache (PHP extension). I'm not that worried about it to be honest... Current version works fine, so...
  16. robdog

    robdog Well-Known Member

    One of your plug-ins I take it?
  17. p4guru

    p4guru Well-Known Member

    yeah i guess...
  18. digitalpoint

    digitalpoint Well-Known Member

    Not really a stand alone plug-in, but it's a small part of a bigger server management framework... This is what my admin page looks like... (lets me see quickly see any issues going on... slave replication lag, high memory swap usage, failed hard drives, PHP errors, loads, uptime [like if a server unexpectedly reboot]), etc.

    p4guru likes this.
  19. p4guru

    p4guru Well-Known Member

    mysql cluser = replication or you have mysql cluster setup ?

    nice i see mariadb 5.5.28a :D
  20. digitalpoint

    digitalpoint Well-Known Member

    The live DB servers are not MySQL Cluster. My servers don't support enough memory for what I want to do unfortunately. They are 6 1/2 years old now, and at the *time* 12GB per server was a ton (the BOIS is limited to 16GB, and has some retarded parameters for how many ranks it supports... and they only have 6 DIMM slots per server).

    I was planning on getting new servers about a year ago, but the floods in Taiwan put that on hold with the hard drives I wanted for them going from $300 to $1,200 per (and I need 72). But I'm thinking the beginning of the new year should be a good time.

    Basically looking at 3 of these rigs:
    http://www.supermicro.com/products/system/2u/2027/sys-2027tr-h71rf_.cfm w/ the 56Gbit Infinband daughter card... but more importantly 256GB of RAM in each server (4 servers per chassis, so 12 total servers). The 16GB DIMMS are fairly cheap these days... the 32GB not so much, otherwise I'd opt for 512GB RAM per server. Basically you can never have too much memory. :)

    I haven't ruled out using Galera instead of MySQL Cluster... it may actually run faster since it keeps a full set of data on each server (MySQL shards it, so you have some overhead of each node sending more than what was requested and the SQL node filtering stuff out). Using MariaDB also has the advantage of it's thread pools system, which is only available on MySQL Cluster if you get the absurdly prices enterprise version.

Share This Page