beta 4 - Upgrade issue : This action is available via POST only.

Ok, now she is looking like this:

Would you just look at those hit/miss rate?

No wonder I had trouble with this 30MB APC. 128MB would make her much happier.

Thank a ton, Deebs

You are most welcome, pleasure to help. Enjoy the speed boost. I am certain it you will notice it.

I also took the liberty of upgrading you from a poor version of APC to a much better version.

I'm not even sure what half this thread's about but speed boosts are awesome.

Appreciate all the help.

I also took the liberty of adding the new user session caching in beta 4 to the config file $config['cache']['cacheSessions'] = true;

Do you think I would benefit from having memcache installed on the sql server since we have a separate server for it.

Possibly, I have just converted my live forums to Libmemcached (advanced version of memcached) and so far so good. Let me grab a pic...

Hm, i would prefer to have ONLY mysql on the server and to give it all the possible memory. (but only because i've read it some years ago )

Edit: found it
http://highscalability.com/bunch-great-strategies-using-memcached-and-mysql-better-together

I have a server with 2GB ram for just mysql and nothing else on it.

XenForo requires a small amount of RAM for the vars and session tables in comparision to a MySQL installation. Having said that, Andy has over 3.5gb RAM free on his webserver so could happily run Memcached there.

what a nightmare this has turned out to be.
ive completely disabled apc for the time being.

The biggest problem with using APC, as Mike as stated, is not having enough capacity to store the vars/sessions in the cache. Have you got any stats ?

Why is this needed? Without it the apc.php user-caching already shows the sessions being cached?

Okidoki, added to my config.php =D

the real nightmare was not being able to login to the acp within 10 minutes of the update, right in the middle of my revert/reapply templating work. eventually i found my way to this thread, then disabled apc.
its worth noting that i didnt opt in to this new session jazz. it might not be a great idea to have this happen to people in 1.1 final.

here are some stats. its (seemingly) run happily with 30 mb for nearly a year now. its running 30 mb cos i heard from people that 30 was some sort of magic number.
if i need to increase this or whatnot i can do that, but for time being my only worry is actual acp access.
what do these numbers relate to you?

Firstly,

That is a way old version of APC and I would recommend uprading to 3.1.9.

The magic number of 30 comes from the fact that many old distros of Linux came with a maximum shared memory setting of 32MB out of the box. Personally I would increase the shared memory size of your server first, then increase the APC memory to 64MB. This will hopefully stop the Cache Full Counts but it will not stop fragmentation (Not seen anywhere that has effectively stopped fragmentation on an APC install running after a few hours)

Mike,

I used to run 4 segments but the caches would still fragment. Perhaps I should try with 3.1.9.

For my variable storage I have implemented Libmemcached with enabled igbinary support and changed PHP session.serialize_handler=igbinary (for that little extra performance).