XF 1.0 Real-World Page Loading Speed

This isn't so much a 'have you seen this feature' post as one that goes some way to explaining why interacting with XenForo is such an immediate, pleasurable experience.

The following is screen-grabbed from Google Webmaster Tools.

 

[p4guru]

Yes. It will probably be one of our first 'big boards'.

(though I do still have a soft spot for good old 3.8 of course)

same on 3.8.5 here myself

maybe for xenforo maybe a vB 3.8.x look a like style theme for folks wanting to be a bit sentimental when they convert over hehe

 

[RobS]

It was tested on a big board, and has been designed with scalability in mind.

In that case, I will be forever in XF's debt. People sure do love those 10,000+ post threads and who am I to deny them?

I look forward to being able to have an empty slow query log and the 2 hamsters powering my server will be very grateful too.

 

[Kier]

XenForo uses a completely different method of fetching posts for a thread, so there should be either a negligible or non-existent performance difference between a thread with a couple of pages of posts and one with hundreds of pages.

 

[Shamil]

XenForo uses a completely different method of fetching posts for a thread, so there should be either a negligible or non-existent performance difference between a thread with a couple of pages of posts and one with hundreds of pages.

Interesting. Is this a new technique that hasn't been used before or something?

 

[Kier]

Interesting. Is this a new technique that hasn't been used before or something?

No idea. It's different from what we used in vBulletin, but I don't know if it's the same as what phpBB, IPB etc. use - I'm not in the habit of reading their code.

 

[Dean]

Yes. It will probably be one of our first 'big boards'.

If it is not too personal, would it be possible to let us know when that will happen? I am extremely interested in how the members react with the change, as that might help when our forum gets converted.

 

[Kier]

If it is not too personal, would it be possible to let us know when that will happen? I am extremely interested in how the members react with the change, as that might help when our forum gets converted.

http://forums.Spacebattles.com is a forum with approaching five million posts, and maintains a high level of concurrency. It is highly reliant upon Sphinx as its search engine to prevent it from murdering this little server. Therefore, Spacebattles won't switch to XenForo until a viable Sphinx implementation is available.

 

[Floris]

Sorry misread that bus as hub (maybe I need more sleep). Nice server specs. I'm on a basic E5504.

I disagree, those are very poor and cheap server specs. A step-in dedicated server.
But it's nice to see that xenforo performs well on it, together with whatever else runs on that box.

 

[Shamil]

I disagree, those are very poor and cheap server specs. A step-in dedicated server.
But it's nice to see that xenforo performs well on it, together with whatever else runs on that box.

The last time I purchased a server was a while ago. I never was into the specs, well, I only looked at 3 components. It's very nice to see that XenForo is running very well on it

 

[vadriven]

For those who use nginx:

location /community/ {
    if (!-e $request_filename) {
        rewrite ^(.*)$ index.php last;
    }
}

Even easier than in mod_rewrite for Apache.

I'm guessing you could also use a similar block as WordPress, without having the code not sure what index.php is expecting to format the query properly, but one of the 2 should work … maybe

location /community {
    try_files $uri $uri/ /community/index.php;
}

location /community {
    try_files $uri $uri/ /community/index.php?q=$uri&$args;

}

 

[Erik]

XenForo uses a completely different method of fetching posts for a thread, so there should be either a negligible or non-existent performance difference between a thread with a couple of pages of posts and one with hundreds of pages.

Excuse my ignorance, but what else is there to do other than

SELECT * FROM posts WHERE thread_id=x LIMIT 0,10

?

EDIT: Unless...

SELECT * FROM posts WHERE thread_id=x AND (post_num  BETWEEN 0 AND 10)

Would theoretically be faster as MySQL doesn't fetch the whole result set and then truncate. Instead it would only be fetching the records you need.

 

[Disjunto]

LIMIT is stupidly slow with a large result set, can't wait to see what they've done

 

[Onimua]

Excuse my ignorance, but what else is there to do other than

SELECT * FROM posts WHERE thread_id=x LIMIT 0,10

?

EDIT: Unless...

SELECT * FROM posts WHERE thread_id=x AND (post_num  BETWEEN 0 AND 10)

Would theoretically be faster as MySQL doesn't fetch the whole result set and then truncate. Instead it would only be fetching the records you need.

You also need to check for which posts you can see. In vBulletin for example, there could be unapproved posts that only as a moderator you can see, you once the software checks your permissions, it has to sort the results based on what you can't see and sort the pages for that. From the Moderation Tools video it seems we have Unapprove Posts/Threads too, so the same thing can be seen here. If we get an ignore feature too (a proper feature, not the way vB did it), then it's even more "sorting" that XF would have to do. There could be other things I'm not thinking of or aware right now but that's off the top of my head.

It's much more than just simply fetching posts associated with a thread. I'm curious to know what method XF is using to do this as it's different from the way vB did it from what Kier mentioned.

 

[Erik]

You also need to check for which posts you can see. In vBulletin for example, there could be unapproved posts that only as a moderator you can see, you once the software checks your permissions, it has to sort the results based on what you can't see and sort the pages for that. From the Moderation Tools video it seems we have Unapprove Posts/Threads too, so the same thing can be seen here. If we get an ignore feature too (a proper feature, not the way vB did it), then it's even more "sorting" that XF would have to do. There could be other things I'm not thinking of or aware right now but that's off the top of my head.

It's much more than just simply fetching posts associated with a thread. I'm curious to know what method XF is using to do this as it's different from the way vB did it from what Kier mentioned.

Yeah, obviously there would be a bit more to the actual SQL query. I was just focusing on the concept of using something other than LIMIT to fetch certain posts.

 

[RobS]

You also need to check for which posts you can see. In vBulletin for example, there could be unapproved posts that only as a moderator you can see, you once the software checks your permissions, it has to sort the results based on what you can't see and sort the pages for that. From the Moderation Tools video it seems we have Unapprove Posts/Threads too, so the same thing can be seen here. If we get an ignore feature too (a proper feature, not the way vB did it), then it's even more "sorting" that XF would have to do. There could be other things I'm not thinking of or aware right now but that's off the top of my head.

I quite like the BBC blogs approach to moderation. They show all comments, but replace the text for the deleted or moderated comments. Moderated comments say something about being referred to the moderators and deleted comments say they were deleted because they broke the house rules.

That always struck me as a better way to deal with it, as you never have to worry about vBulletin's 'visible' hitting the right indexes, you can just show everything. One less complicated index in the database is always a bonus too.

It's much more than just simply fetching posts associated with a thread. I'm curious to know what method XF is using to do this as it's different from the way vB did it from what Kier mentioned.

I'm very interested too. Very, very interested.

 

[Onimua]

I quite like the BBC blogs approach to moderation. They show all comments, but replace the text for the deleted or moderated comments. Moderated comments say something about being referred to the moderators and deleted comments say they were deleted because they broke the house rules.

That always struck me as a better way to deal with it, as you never have to worry about vBulletin's 'visible' hitting the right indexes, you can just show everything. One less complicated index in the database is always a bonus too.

I find that as unnecessary clutter in a thread though. I want to read comments, not read comments and blocks of text saying a comment was there but I can't read it. Why show it if I can't read it?

 

[RobS]

I find that as unnecessary clutter in a thread though. I want to read comments, not read comments and blocks of text saying a comment was there but I can't read it. Why show it if I can't read it?

In regards to moderation, that might be beneficial. Currently, we automatically moderate any posts that contain URLs from new registrants. If you're slow to approve/delete like we often are, it's useful to let people know that they're not alone in having to wait.

With deleted posts, I can see where you're coming from, but we rarely delete posts anyway, so I'd prefer a performance boost, however slight, to an occasional annoyance. I'm hoping that won't be an issue with xF anyway though.

 

[Peter Hall]

You also need to check for which posts you can see. In vBulletin for example, there could be unapproved posts that only as a moderator you can see, you once the software checks your permissions, it has to sort the results based on what you can't see and sort the pages for that. From the Moderation Tools video it seems we have Unapprove Posts/Threads too, so the same thing can be seen here. *snip* It's much more than just simply fetching posts associated with a thread. I'm curious to know what method XF is using to do this as it's different from the way vB did it from what Kier mentioned.

If I was writing a post moderation/deletion feature I wouldn't do it the traditional way - i.e. leaving the post in the posts table and changing a field to mark it as hidden. Under the assumption that most people won't have the permissions to view the post, I'd delete it from the DB, put it in a different table and use a UNION query to allow people with the appropriate permissions to see it. That way, the extra load is only on requests made by moderators and admins, instead of having a deeper index to deal with.

So, the post_num query might even work, unless you're a mod or an admin, in which case you'd have to do something totally different - but perhaps that's fine. In fact, if you were crazy enough, you could go completely to town with it and have a joint primary key on the table with thread_id and post_id - just set post_id to auto_increment and it happily starts a new thread at post_id 1, all by itself... but you'd need some pretty heroic code to make that work system-wide. I wouldn't want to write the split/merge thread features for it anyway.

 

[Walter]

You get a performance penalty for a union - and this isn't efficient because deleted posts are quite rate (at least compared to regular posts).

 

[Peter Hall]

You get a performance penalty for a union - and this isn't efficient because deleted posts are quite rate (at least compared to regular posts).

The point is that the performance penalty only occurs for people with permission to see deleted or unmoderated posts, rather than for everyone else. Relatively few people have those access levels, so it's more efficient on aggregate.