XenForo + caching = AMAZING

Anthony Parsons said:
I honestly don't see any significant changes in those results, in the scheme of performance.
Click to expand...
First, I want to apologize as I forgot to disable the htaccess protection on previous tests. I was wondering why I was getting such high number of transactions. o_O
But regardless of that, I was simply trying to highlight that "APC (alone) shows far better caching performance" statement is false. The bursts I ran are extreme and they emulate intense activity. In other words, all of 500 users visit 50 url's at random intervals less than 1 second.

Of course, everyone can choose to setup their server as they are pleased. I've been doing performance setups on site clusters with over 20 servers built from scratch, so I know how important are these numbers. Even the slightest improvement is crucial.

Memcached/Igbinary/APC Burst Tests
Code: 
# siege -c 500 -d 1 -t 30S -i -f /etc/siege/urls.txt
** SIEGE 2.72
** Preparing 500 concurrent users for battle.
The server is now under siege...
Lifting the server siege...      done.
 
Transactions:                  3279 hits
Availability:                  93.50 %
Elapsed time:                  29.73 secs
Data transferred:              27.05 MB
Response time:                  3.43 secs
Transaction rate:            107.65 trans/sec
Throughput:                    0.89 MB/sec
Concurrency:                  368.95
Successful transactions:        3279
Failed transactions:            228
Longest transaction:          25.84
Shortest transaction:          0.37
 
# siege -c 500 -d 1 -t 30S -i -f /etc/siege/urls.txt
** SIEGE 2.72
** Preparing 500 concurrent users for battle.
The server is now under siege...
Lifting the server siege...      done.
 
Transactions:                  3263 hits
Availability:                  90.84 %
Elapsed time:                  29.91 secs
Data transferred:              26.90 MB
Response time:                  3.44 secs
Transaction rate:            107.79 trans/sec
Throughput:                    0.89 MB/sec
Concurrency:                  368.62
Successful transactions:        3263
Failed transactions:            225
Longest transaction:          22.94
Shortest transaction:          0.47

APC Only Burst Tests
Code: 
# siege -c 500 -d 1 -t 30S -i -f /etc/siege/urls.txt
** SIEGE 2.72
** Preparing 500 concurrent users for battle.
The server is now under siege...
Lifting the server siege...      done.
 
Transactions:                  3240 hits
Availability:                  90.88 %
Elapsed time:                  29.49 secs
Data transferred:              26.81 MB
Response time:                  3.41 secs
Transaction rate:            106.87 trans/sec
Throughput:                    0.91 MB/sec
Concurrency:                  374.66
Successful transactions:        3240
Failed transactions:            325
Longest transaction:          16.30
Shortest transaction:          0.43
 
# siege -c 500 -d 1 -t 30S -i -f /etc/siege/urls.txt
** SIEGE 2.72
** Preparing 500 concurrent users for battle.
The server is now under siege...
Lifting the server siege...      done.
 
Transactions:                  3244 hits
Availability:                  93.03 %
Elapsed time:                  29.82 secs
Data transferred:              26.61 MB
Response time:                  3.45 secs
Transaction rate:            105.79 trans/sec
Throughput:                    0.89 MB/sec
Concurrency:                  375.05
Successful transactions:        3244
Failed transactions:            243
Longest transaction:          24.78
Shortest transaction:          0.33
 
Floren, what is the overhead sacrificed to obtain those marginal improvements by running multiple caching software? Does that not then negate those minor performance improvements, or have you not measured that side of this?
 
Anthony Parsons said:
Floren, what is the overhead sacrificed to obtain those marginal improvements by running multiple caching software? Does that not then negate those minor performance improvements, or have you not measured that side of this?
Click to expand...
The CPU overhead is minimal and well worth for overall server stability. Please remember that I performed these tests mainly to highlight that APC alone does not perform far better. From what you said in the earlier post I would expect at least a 50% improvement of using APC alone, compared to APC/Igbinary/Memcached. Regardless, using the trio setup is pointless on a single server setup unless you want to keep your fragmentation at zero levels. Which it was the original goal of the discussion. :)

Allow me to talk a bit more about APC fragmentation, as many people do not understand it. Since APC uses shared memory for its cache, the fragmentation symptoms are subtle and you will not notice anything rightaway. However, over time your active site starts slowing to a crawl, yet you have not changed anything related to your server setup. You can look into logs for issues, you will not find anything and restating your php-fpm service or rebooting the server will bring back your site to its original blazing speeds. Technically, APC fragmentation occurs when a newly cached segment does not fit anymore into its previously allocated space.

Obviously, eliminating the fragmentation completely will maintain your site health and keep things running smooth always. So that is the main reason why you should use the APC/Igbinary/Memcached combo in a single server setup, not because it produces 5% improvements over APC (alone) with a 0.1% server overhead.
 
For anyone who has set PHP to use Memcached as the session handler, that you also update the session.save_path variable, as the syntax is different between memcache and memcached.

Before:
session.save_path ="tcp://127.0.0.1:11211"
After:
session.save_path = "127.0.0.1:11211"

My OpenCart shop has been broken since last Wednesday :(
 
just a question

if you install memcache and APC on cpanel vps accounts.
do you need to have retain the eAccelerator installed by default?
 
MattW said:
Memcached server 1.4.14 is now out. Upgraded both my installs this evening
Click to expand...

I bumped mine to 1.4.14 the other night when I bumped Libmemcached up a few points too ... :D

The speed difference (for the overall work) is great and the lower load is making a big difference; sites are running much quicker now - well worth the effort. (y)

I did get to a plateaux though with Libmemcached and could only get up to 1.0.4 (newer versions failed to compile). Maybe another package it depends on needs updating on my server or something, who knows, for now I've stopped "fiddling" with it. :ROFLMAO:

Cheers,
Shaun :D
 
Floren said:
I posted this setting into previous post, didn't I? :cautious:
Click to expand...

Ah, yes you did. I didn't see that. However, my setup doesn't use .ini files for the individual configs, they are all inside the main php.ini. I didn't have issues with xenforo, just opencart, which is why it took so long to notice.
 
Just to clarify, I don't think I ever said APC would perform *much* better... only that the overhead of network connections and such to memcached make a very *marginal* overhead that isn't necessary in a single server setup. APC and memcache in a single server setup are both going to be fast. And if you think you are going to be expanding to a multi-server setup, starting with memcache might make more sense just so you don't have to change your caching backend.

Either way, both options are going to be fast. I mean I can make a non-persistent connection to memcached, write a value, read it back, delete it and then disconnect in about 0.4 ms, so...
 
Just updated APC to 3.1.12 which was released yesterday

- Fixed bug (apc_bin_dump doesn't swizzle bucket arKey in HashTable) (Laruence)
- Fixed bug #62825 (php carshed OR return PHP Fatal error when used apc_bin_dump after apc_store) (Laruence)
- Fixed bug due to Conditional "jump or move depends on uninitialised value(s)" in apc_op_ZEND_INCLUDE_OR_EVAL and apc_bin_dump (Laruence)
- Fixed bug #62802 (Crash when use apc_bin_dump/load) (Laruence)
- Fixed bug #62757 (php-fpm carshed when used apc_bin_dumpfile with apc.serializer) (Laruence)
- Fixed bug #62765 (apc_bin_dumpfile report Fatal error when there is "goto" in function) (Laruence)
- Fixed bug #61133 (segfault in tests/apc_bin_002.phpt) (Laruence)
- Fixed handling of userspace stream wrappers simulating file inclusion/requiring (Anatoliy, Rasmus)
- Fixed bug #62699 trait aliases and precedences handling (Anatoliy)
- Added cli built-in server tests (Anatoliy)
- Fixed filter regex freeing on request shutdown (Anatoliy)
- Fixed interned strings storage freeing on module shutdown (Anatoily)
- Fixed bug #61742 preload_path does not work due to incorrect string length (Anatoliy)
- Fixed several memory leaks it APCIterator (Anatoliy)
- Fixed potential overflows in bin dumps (Anatoliy)
Click to expand...
 
Cpanel still shows 3.1.9 if you install it via that. I do it via command line,

download the latest gz file from the PECL website.

then:

Code: 
tar -xzvf APC-3.1.12.tgz 
cd APC-3.1.12
phpize
./configure
make
make install

restart apache....job done.
 
You must log in or register to reply here.

Similar threads

DiscussionBucks
  • Question Question
XF 2.2 Assistance Needed: Disabling Xenforo Caching/Service Workers to Resolve Ezoic Integration Issues
Replies
2
Views
59
rdn
R
ForumExplorer
Xenforo is amazing
Replies
13
Views
1K
Davyc
Davyc
Moscato
Few questions about xenforo caching
Replies
9
Views
2K
Marcus
Marcus
I
Xenforo Caching with Nginx on Ubuntu 14.04LTS
Replies
5
Views
1K
MattW
MattW
Ketola
New XenForo setup questions (clustering, caching etc.)
Replies
10
Views
8K
Floren
Floren
Back
Top Bottom