XF 1.4 XenForo is not performant

[au lait]

We operate a very large forum in which at any time more than 3,000 users are online and at peak times almost 5000 users.
We have around 2000 forums in our forum and this make problems. It seems to be XenForo is unlike vB not optimized for large forums.

Have both forums tested locally - the vB version (without addons) and XenForo (without addons) each with standard style (ok, with one modification in XenForo see below).

Affects Forum Home:
vB 3.8 = 0.24201 seconds and 16,791kb
XF 1.4.10 = 1.1892 seconds and 25,949kb
And it is not the queries that are so lame: 0.1317s for queries

As you can see, XenForo can not handle Optimal with this amount. And due to the above access numbers of the users this is more than unacceptable.

Just so we're clear, these are the values without subforums! Which have already been in the class XenForo_ControllerPublic_Forum recessed,

in the of:

'nodeList' => $this->_getNodeModel()->getNodeDataForListDisplay(false, 0),

to:
Code:

'nodeList' => $this->_getNodeModel()->getNodeDataForListDisplay(false, 2),

has been changed.
Otherwise it look even worse!

In addition, the subnodes were removed from the template. Because with subnodes, the time in 2.9087 seconds! ABSOLUTE **** !!!! (Sorry)

I hope that here XenForo quickly optimized!
Because the problems are like a red path through the system. So that's creating new forums one thing that also likes to go in the pants.

And now please do not say things like - away forums or so. It even come still more to the page!

Technical specifications:
1x Loadbalancer (6GB Ram, i7 920)
2x Web Server (48GB Ram, 2x Xeon X5650)
1x Fileserver (NFS, 2x 240GB SSD Raid 1, 8GB Ram Cache)
1x DB Server (24GB Ram, i7 980, 2x 160GB Intel DC SSD Raid 1)

In the config.php is frontend and backend cache registered

 

[Mike]

The reality is that each node you create has overhead. Every node is considered for permissions, then for "pushed" data calculations and then needs to be fully rendered. You've minimized this to some degree by limiting the depth calculations, so I'm curious how many nodes are still being rendered. It's probably a bit slower than I'd expect.

However, in general, we wouldn't consider 2000 nodes to really be a "normal" or anticipated use case (and I don't really think it's a great setup, but you may have specific needs). We certainly would have recommended against it.

 

[Xon]

@au lait it would be interesting to see a profile graph of that using xdebug & webgrind or similar.

I suspect you'll see a bunch of inefficiencies from the XenForo_NodeHandler_Abstract interface which don't matter with a small node count, but without profiling it is hard impossible to determine why you are seeing such a large increase.

 

[au lait]

@Mike
may be so, but it's not in XF interest even to be efficient as vBulletin?
I think this is now a great shame.
It should not matter how many nodes! Or XF is only for small forums ;(

Under vB it run performant!
In such forum, it does not go with less forums! And under vB It was indeed!

 

[ge66]

I would try to use Prefix and Tags to get fewer forums.

 

[dutchbb]

The number of posts (not that huge even) vs nodes does not make sense to me, agree with ge66. I mean our forum has more posts and I'd go insane having to keep track of that many nodes :s

 

[Donny]

Prefixes, and, generalise a little!

I don't split a forum node into two more useful nodes until it's becoming hard to find threads and the search function when searching the said node becomes a bit lazy because of too many similar threads etc.

I can't see a benefit in having that many nodes for 3000 members. They've got a node and a half each!

 

[JulianD]

I can't see a benefit in having that many nodes for 3000 members. They've got a node and a half each!

I I understand correctly, it's 3000 users online, peaking at 5000.

 

[Donny]

Ohhhh okay. Sorry my bad.

 

[ForumCube]

I agree with @Mike and other folks that your setup not sounds normal. But if you really want to live with it then I thin you should best get your server setup optimised.

The provided tech specs are pretty much discussing the hardware side of things but what about actual server setups? I think that matters a lot as we seen very good results choosing the right server setup.

 

[au lait]

Server Specs are in the 1st post.

The server can wonderfully with vBulletin generate Forum Home in 0.2 seconds.
XenForo manages the same task - on the same server - in 1.1 seconds.

And then you say, which is on the server? Sorry, for me it looks more like murks within XenForo out!
How can it be? Same data in 2 different softwares on the same server. It should be on the server when one software is slower than the other - clearly is of course easier. ;-)

But hey OK!
I like to place the nodes / forum / thread tables for a test on your servers available! Your attempts themselves and then we'll see. Not that I have not done this already 5 times before ...; (

 

[TPerry]

But hey OK!
I like to place the nodes / forum / thread tables for a test on your servers available! Your attempts themselves and then we'll see. Not that I have not done this already 5 times before ...; (

But Hey.. OK.. MyISAM vs InnoDB anyone?
MySQL tuned for InnoDB?
I didn't see where you stated which engine was being used for vB and XenForo.

 

[HWS]

If I would need to run a forum with > 2000 nodes, I would enage a coder and server administrator and have it optimized myself. I would have several ideas what should be done, including prerendering and caching the forum home page.

XenForo out of the box is simply not the correct software for you. It is like to buy a Prius and expect it to drive like a Ferrari.

 

[ForumCube]

From my experience XF works a lot better then vB and other forums. As most of the folks in this thread are saying your use case is not common you should consider hiring someone for getting your server better optimized. Generally following changes help a lot:

• MySQL to MariaDB (There is on average 30% improvement)
• Use Nginx as reverse proxy to Apache
• Use enhanced search that perfectly utilizes Elasticsearch

Simple smart techniques and arrangements can actually save you a lot from hardware and ensure that things work much better. Also if you got 2000 nodes then stuff like Query & Table caching can increase the speed of your forum.

XenForo out of the box is simply not the correct software for you. It is like to buy a Prius and expect it to drive like a Ferrari.

I slightly disagree with this example. They are actually buying a Ferrari and then trying to use it as cargo truck.

 

[Mouth]

And caching!? I assume your XF installation is in a test environment, and thus your DB queries and page loads in sampling will be from expensive and slow disk, instead of having the majority of data preloaded in DB and php cache from constant user hits.

 

[Mike]

The comments about MySQL optimization aren't really well placed. He commented on that already. That said, .13 of the time on queries is more than I would expect.

I've been testing and profiling with 1000 forums (with a random distribution between level 1 and 4). I found one place where a single call to strtr was much slower than I expect; changing to a few str_replaces was actually significantly faster. Beyond that though, most of the work is simply from template rendering. The entire tree is generally rendered, even if they've been taken out of the templates (it is in them by default). Limiting to grabbing the first 2 levels should limit this though, though it will make counts/last posts incorrect. If you want to only render the first 2 levels but fetch all the data, that would require some custom development to do filtering in the view, before rendering. Since I see only 50 nodes being rendered, this would likely solve the performance issues for you.

My tests are somewhat contrived and hacked together with a script, so a real node tree would be helpful. Dumps of the xf_node and xf_forum tables would let me test with the correct data. PM me about that if you can send that over so I can profile it to see if anything different comes out with real data.