What is the slowest part of XenForo and how would you improve it?

Adam Howard

Well-known member
I made a post about this earlier and maybe posted it in the wrong forum. And I think it was lost in miscommunication. So since this is a general topic, lets try here.

I love XenForo :love: It's very modern, fast loading, user and mobile friendly. (y)

However the rule of technology (universally), is it can only be as fast as it's slowest part.

For example, I can buy the newest i7 Intel CPU, pop in the latest motherboard, and load it with a server grade SSD drive, but if I go cheap on the ram that would be my bottleneck or the slowest part.

I hope I've explained the "slowest part" concept in away most people can understand it. :) But if not, please give your own example. ;)

Software is no different and that includes forum software. No matter if you compare vBulletin, IPB, Burning Board, phpBB, SMF, or even XenForo there will be some point that you can say is the slowest part.

XenForo is fast and I love it. :love:

But to me the slowest part appear to be deferred.php Even on XenForo.com running the file by its self is still 1/2 a second (between 200 - 500 ms)

http://xenforo.com/community/deferred.php

Which of course calls upon

/library/XenForo/Autoloader.php

I've not really dugged to deep into the code & only have noticed how things load in Firebug. And of course 1/2 a second is nothing to cry about. XenForo should be proud that it's "slowest part" is only 1/2 a second compared to others.

Of course if you disagree with my opinion.... Where would you believe xenforo could be improved upon (where is it's slowest part)?
 
Last edited:
The slowest part in my opinion revolves around how MySQL needs to process all omitted records before a LIMIT. This means the higher page number you are viewing in a forum (list of threads), the slower.

You can see this by going to a normal forum, page 1... for example:

https://forums.digitalpoint.com/forums/domains.59/

Then in the same forum, go to a much higher page (let's say page 1000):

https://forums.digitalpoint.com/forums/domains.59/page-1000

My site will actually be slower than most in that case because we don't use a storage engine that has all data on a single server (like InnoDB or MyISAM). We use ndbcluster, which takes parts from multiple servers and reassembles them (99.99% of the queries will be faster, but some are not). Either way, all storage engines are affected to some degree of performance degradation the higher the LIMIT value in the query is.

XenForo did a really good job solving this in threads by storing the post "position" within the thread so it doesn't need to use the LIMIT clause. Not sure if there's a realistic way to do the same with threads within a forum since they can be viewed so many different ways (various sorting and filtering options would make the position value unique to each combo).

I did start working on it within an internal "Scalability" addon I have, and got most of it done. Basically I have it storing a unique position value for each sort type that regenerates all the position values in that forum when something changes (like a new thread or someone replies). I figured I would use those for displaying thread vs the LIMIT query when it can (when there isn't extra filters like prefix filtering), and fall back to the default method when it can't. One of these days I'll finish it. :)
 
Top Bottom