Not planned optimize deferred

Adam Howard

Well-known member
Every forum software has a bottleneck somewhere. Doesn't matter if you're using IPB, vBulletin, phpBB, SMF, Burning Board, or even XenForo.

Much like a computer, it is only as fast as it's slowest part.

In the case of XenForo that would 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

This seems to vary depending on how many people are online & I would assume whatever process is being run... ie... post, edits, search, ect....

But knowing where that bottleneck is means knowing what needs to be improved. And with it being only in or about 1/2 a second, it's not like it's mission critical or something to really make a fuss over.

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:
Upvote 0
This suggestion has been closed. Votes are no longer accepted.
It comes in at 300ms for me on this site... but truthfully, I'm not sure it's worth the time to see if MAYBE you could try to shave 0.1 seconds off something that is decoupled from the user experience.

The whole point of it is to offload stuff away from the user experience.

I'd be way more interested in having a better trigger mechanism so deferred isn't called ~420 per minute (see this thread). :)

I ended up just making mine run on a normal shell cron job once per minute, and not normally through a user triggering it.
 
The entire point of deferred.php is to run slow tasks in the background.

The reference to the autoloader is strange - if you think the autoloader is being your bottleneck, then you're generally saying that either there's no opcode cache or if there is, the stat checks are the problem. If you're not saying this, then it's basically just saying that PHP is slow. :)
 
The entire point of deferred.php is to run slow tasks in the background.

The reference to the autoloader is strange - if you think the autoloader is being your bottleneck, then you're generally saying that either there's no opcode cache or if there is, the stat checks are the problem. If you're not saying this, then it's basically just saying that PHP is slow. :)
I'm saying when looking at the code for deferred.php there also happens to have a reference in it for Autoloader.php

I'm also saying that as far as I can tell that is the slowest part in XenForo, even here on XenForo.com (between 200 - 500 ms). @digitalpoint even clocked it here at 300ms

It comes in at 300ms for me on this site...

All of this is not bad per say. I mean 1/2 second is nothing to cry about. The point of this thread was...

This topic was meant to be a discussion on what is the slowest part of XenForo and how could that part be improved?

Maybe I posted this in the wrong forum and so it was lost in miscommunication.....
 
Last edited:
This topic was meant to be a discussion on what is the slowest part of XenForo and how could that part be improved?

Probably deferred tasks, we could try deferring them so that they don't effect the user's experience. :p
 
Last edited:
Top Bottom