XCache 3.0.0

[Brent W]

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

 

[digitalpoint]

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*...

 

[Brent W]

I opened a ticket: http://xcache.lighttpd.net/ticket/292

htdocs is the new admin folder.

 

[digitalpoint]

Oh yeah... that does work way better.

 

[Shamil]

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.

 

[AdamD]

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

 

[digitalpoint]

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

 

[p4guru]

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

haha i know what ya mean

MySQL -> 5.5.28
Memcached -> 1.4.15
Memcache -> 3.0.7

 

[digitalpoint]

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.

 

[Deebs]

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.

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?

 

[digitalpoint]

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).

 

[Deebs]

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).

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

 

[digitalpoint]

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.

 

[p4guru]

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

 

[digitalpoint]

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...

 

[robdog]

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

One of your plug-ins I take it?

 

[p4guru]

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...

yeah i guess...

 

[digitalpoint]

One of your plug-ins I take it?

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]

mysql cluser = replication or you have mysql cluster setup ?

nice i see mariadb 5.5.28a

 

[digitalpoint]

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.