How good is XenForo plugin architecture?

[Rigel Kentaurus]

I was inspired by the post that digitalpoint made here, about the performance impact about installing lots of plugins. Since I care about the speed of my site, that is a huge deal.

So, here is a benchmark

Average load time
Before plugins - 0.813 seconds
After plugins - 1.151 seconds

There are some 300 milliseconds involved into there, which means that features that I have added to my forum are contributing to the load time, substantially. Some well-known hacks that I have are...

• Who has viewed this thread
• Latest posts in forumhome
• Extra BB codes
• A bunch of template edits I do through plugins

Most of these are specific to my site (I wont share details), but to give you a sense of the amount of modifications, it is 29 addons, consisting of 169 files total that contain 5826 lines of code

You'll have to take my word into saying that all of them have been beautifully coded and are as optimized as possible.

That means that, adding plugins to my site is contributing to roughly 29% of the render time. That is not that bad, actually, since everything is designed to be really elegant, I can deal with that. The site still loads under 1.2 seconds

Let me repeat that. A simple XenForo installation, with a lot of plugins, still loads fast, for me under 1.2 seconds

 

[Jeremy]

If you have suggestions / knowledge where extra BB Codes slow down the site for you, please send me a PC. I will look into them.

 

[Rigel Kentaurus]

If you have suggestions / knowledge where extra BB Codes slow down the site for you, please send me a PC. I will look into them.

Well, site is not crawling, really, nor slow. It is kind of expected that after adding some plugins there will be some overhead. After all, the CPU power required for processing the additional options is greater than zero. Even with plugins that are written to be O(1) there is a little performance hit.

Actually, it isn't that bad considering it is 169 files worth of modifications.

Thanks, for the offer, though ! If I ever see that an 80% is because of bbcode or something like that I know who to call

 

[Jeremy]

Well, site is not crawling, really, nor slow. It is kind of expected that after adding some plugins there will be some overhead. After all, the CPU power required for processing the additional options is greater than zero. Even with plugins that are written to be O(1) there is a little performance hit.

Actually, it isn't that bad considering it is 169 files worth of modifications.

Thanks, for the offer, though ! If I ever see that an 80% is because of bbcode or something like that I know who to call

It is pretty good. And yes, if you get hit with a BBCode that bad, wow. lol. And I just cringed when I read O(1). I hate run-time and algorithm analysis.

 

[Floris]

XenFans currently counts 19 back-end plugins and 23 front-end plugins. As small as some are, they seem to be affecting the site's performance according to you. I feel no realistic difference loading the site without and with them, to be honest. Note though, that I don't run major plugins that affect posts (except a super-admin plugin only executed when super-admin views a post).

 

[ragtek]

• Who has viewed this thread
• Latest posts in forumhome

these 2 could slow it down.
specially if you have a big forum and the queries aren't optimized

 

[Rigel Kentaurus]

XenFans currently counts 19 back-end plugins and 23 front-end plugins. As small as some are, they seem to be affecting the site's performance according to you. I feel no realistic difference loading the site without and with them, to be honest. Note though, that I don't run major plugins that affect posts (except a super-admin plugin only executed when super-admin views a post).

Floris, I would recommend that you run a profiler or some load-testing tool and measure the actual difference. I do not see any difference on my site either while browsing. The min time is 657 ms (less than 1 second), the average and 90 percentile are more significant about the actual user experience.

Some of these numbers are milliseconds with which we humans do not deal very well. The issue in place is scalability and the throughput that I can handle with one server with everything loaded on. There is some overhead from loading php files and extending classes using the XFCP system, thought it is not in the scale of seconds, it is not zero either. The question for me was "will XenForo grow with me, or will it be a nightmare once I start adding things"

 

[Rigel Kentaurus]

these 2 could slow it down.
specially if you have a big forum and the queries aren't optimized

I actually roll my own version of the hacks (unless something is done really good).

The forumhome one, it fetches the newest threads every 15 minutes through a cron job, and stores the result in a memcached variable. The memcached variable is read for forumhome. This means there are no additional database queries.

The who has viewed this thread, I piggyback on the view count , and then store the information on a serialized array on a field on the thread table. This enables me to fetch everything with no additional queries on thread view.

So, pretty much, for me, none of these add queries at all.
Tricks that I learnt by optimizing a big vBulletin forum

 

[Floris]

I think less than a second is neglectable for my sites. We don't have 1,500+ users online constantly for example. And I doubt it will in the future.

 

[Floris]

To be honest, I think it's very logical that time, and i/o, and resources are going to increase when you use anything on top of any product. You hook into the system, use more PHP and MySQL, and that's not causing "lag" at all, it's just causing more stuff to do. If they introduce a new feature in 1.1.1, the load time might be those milliseconds you now experience as well. How well the plugins are written is the real question. Does one forum index plugin introduce 15 new queries? Is the data changing constantly, or could it be cached, if it's a cache, is it using a crontab entry to not further stress the system and users when it's not needed?

I doubt you will notice a realistic difference installing 50 or 100 plugins. Sure, the load on the server might go up slightly, the i/o might be more, and more resources might be used. But the site will be loading what, a second slow because you have more than 50 installed anyway?

I don't think personally that the difference on site with perhaps 5 or 25 plugins is saying anything about a heavy traffic web site with millions of posts, thousands of online users constantly, and let's say a hundred plugins.

that said, even if i am wrong, because i am not a programmer, etc. I doubt phpbb/smf/vbulletin/ipboard will be able to NOt have i/o increasement, use less resources, or deal better with thousands of online users when you have 100+ plugins installed.

 

[Rigel Kentaurus]

When the files included by plugins start to be in the hundreds, yeah, I start to care about how they are loaded and how they are impacting the overall performance.

The rest, no comments. You need to do that, too. Actually, first. One bad addon can bring the site down.

 

[Floris]

I agree with you on that.

 

[Robbo]

How it works is better than any other PHP software I have used. If you have problems it is because of the add-on authors. I have looked at a lot of the add-ons here but haven't seen many written very well. It will get better over time.

 

[Floris]

How it works is better than any other PHP software I have used. If you have problems it is because of the add-on authors. I have looked at a lot of the add-ons here but haven't seen many written very well. It will get better over time.

I am certainly not a good coder, if it works, I am happy. Of course, I try my best to do my best and a bit beyond.
If you see anything wrong with my plugins you're always free to request the latest dev build and update it with code contributions and I will release the updated version as a new one, with full credits.

 

[Forsaken]

If you have problems it is because of the add-on authors. I have looked at a lot of the add-ons here but haven't seen many written very well. It will get better over time.

Were you included in this statement?

 

[Rigel Kentaurus]

It will get better over time.

Without trying to be negative, if experience is an indicator, it will not, it will get worse, much worse.

My experience with vBulletin.org is that when it was a small community, the addons were overall better in quality, there wasn't as much selection but the people there usually knew how to code. They were the early adopters, after all, and that crowd is usually a techy crowd.

As vB started growing the crowd became less and less specialized, bunch of addons really poorly coded were introduced, almost anybody tried to do an addon by copying others or following tutorials. That is ok from the point of view you can get lots of things for customizing the forum, it is not ok from the sense that some people were introducing 2 GLOBAL queries, or doing full table scans, or pigging the memory, and they didn't care.

There was never an indicator of "addon" quality. There are some exceptions of people that code exceptionally good. But the rest, not so much.
I had to stop using addons from vB and either code my own or hire someone. I could not risk an addon bringing down my forum.

 

[EasyTarget]

Rigel I agree with you. XF was designed from the ground up for add-ons integration. Although many people don't understand the finer points of database queries and their effects on performance. Many times you don't need to write an additional query because the information is available at the execution point. Understanding how to use the .php debugger can save lots of overhead.

 

[EasyTarget]

I actually roll my own version of the hacks (unless something is done really good).

Do you post any of them here? Best way for others to get better is to learn from someone who knows what they are doing.

 

[digitalpoint]

Once I get done building all the custom stuff I need to build for my site, I'm probably going to have 500+ listeners.

Already thinking I might need to build something that takes all the listener PHP files and compiles them down to a single one for each type of listener. I suspect including 500 PHP files (even if they are individually small) and extending 500 virtual classes for the listeners is going to be no bueno.

http://xenforo.com/community/threads/compile-each-event-listener-type-into-single-php-file.22301/

 

[Digital Doctor]

Once I get done building all the custom stuff I need to build for my site, I'm probably going to have 500+ listeners.

I wonder if there could be some sort of "Community Codebase" where frequently used code / listeners are a part of the Codebase.
I have no idea if it would be useful or disaterous.
The idea would be to "integrate" addons more easily with each other.
Forinstance, a Tags addon could expose it's methods to other projects like galleries, and wikis and articles.
Thus the coders of galleries, and wikis and articles could utilize the Tagging framework for their addons.

I do see a trend towards coders releasing their own frameworks. Which I am sure has strengths and weaknesses.