XF 2.3 Validating data on certain events and it's performance implications

Liam C.

Member
Hi there - I am learning and tinkering around with Xenforo Development. I've watched majority of the videos made by Xenforo as well as taken inspiration and guidance from other addons however I have a question.

We are currently considering a custom AutoMod solution - this would essentially validate specific data. For example, when a user were to sign up on our Forums site, we would like to validate whether or not the Date of Birth is a certain date (as we notice majority of our bots go for the exact same Date of Birth).

Another one is to check the content of a message and validating it before sending. So the use case here is to disallow all websites apart from the ones we have whitelisted. I have already set up the options for this, and they output properly, etc.

The issues I am currently facing is on how we can properly access these events when it occur (so 'onThreadSend') as well as whether it has a major performance implication.

Regarding performance implications - I'm also considering using it in certain cases, for example if the user's account is new or without any roles - it performs the check thus reducing any extra queries as they are deemed as unlikely spam.

Many thanks!!
 
The issues I am currently facing is on how we can properly access these events when it occur

It depends on the specific event.

Sometimes it's easier to use a Class extension to hook into an event - sometimes it's easier to use one of the pre-defined code event listeners.

You need to trace through the code that causes the event and identify a good spot to hook into - usually around the point where the action is saved to the database.

whether it has a major performance implication.

Anything that relates to a single infrequent operation (eg user registration), is not going to cause issues.

Anything that relates to an operation by a single user that doesn't affect other users (eg submit a post), is only going to cause issues if your validation process takes significant time to complete - if it causes users to experience a delay when posting - and especially if it actually times out the operation, you're going to get frustrated users and duplicate posts. Be especially cautious if relying on cloud based systems which may cause delays in responses - any API calls you make should have short timeouts and fail gracefully.

Anything that relates to an operation by multiple users that occur frequently (eg reading a post), is something that should be treated very very cautiously - avoid inserting any delays into this process if possible.
 
Thank you! That is a massive help!!!

to trace through the code
I will look into tracing the code, right now I'm running it off a VM and creating the addon without seeing Xenforo's side at all... so I'll have to fix that in order to do so
multiple users that occur frequently
That is extremely useful

I'm creating new routes with a new page_container, etc so do you have any advice on how many queries I should be reaching per page load?

Apologies for the late reply!
 
I'm creating new routes with a new page_container, etc so do you have any advice on how many queries I should be reaching per page load?

That's a really a "how long is a piece of string" type of question - there's no right or wrong answer.

Not all queries are made equal either - some simple queries will be very quick to complete and are easily cacheable by the database engine. It's the complex queries that take time to complete you need to be careful with. Writes are almost always slower than reads - so extra care required there too. The performance of your database server will have a significant impact on things too - so make sure your production database server is properly tuned.

Either way, the general guide for queries is "as few as possible" and make sure they are optimised and your tables use indexes etc.

Don't forget there are also caches available for applications to use - there's the SimpleCache built in to XenForo, but you could also install Redis or other systems that could be used for caching.
 
Hm okay, thank you.

I am not writing to the database that often during queries. We have two pages that require writing and that is an action that is done less than 20% of the time per day, and even less per month, it's primarily reading data. And yes, I'm making sure to use as little queries as possible!

Do you have any thoughts in regards to cron jobs? I am fetching external API data every 30 minutes for around 45 users to save to a table as well as two other cron jobs that are ran daily and then another weekly

Again, appreciate your help a lot. Performance was a big concern and your help is much appreciated!
 
Cron tasks are generally fine - they run asynchronously from any user interaction so won't impact on user experience

Indeed if possible it is always better to use a cron task to do external API calls rather than doing it synchronously with user activity - so it sounds like you are on the right track there
 
sounds like you are on the right track there
Glad to hear that, much appreciated

I'd try to avoid SimpleCache for everything that is not a) really small and b) required on every page - otherwise it's pretty inefficient.
Hm okay, I can only think of one case of cache - we are saving data to a table every 30 minutes and this data is displayed on a home-page of sorts in which it contains both data unique to the user (in terms of it is only their data) as well as data that is relevant and seen by all users who has access to that page

We have around 40 people per forum site on that page, it's intended to be somewhat visited often. As this data is refreshing every 30 minutes, it seems likely that SimpleCache would be a good use here to avoid repeated database calls. Would you agree or is it unnecessary for the amount of users?

I do not think I will be installed Redis, I'd rather not add anything more to our forum site than what is necessary.
 
SimpleCache is limited in the size of data that can be returned - so storing data for every user is very likely to cause issues.

You might get away with storing data for only 40 people - but only if the data is small.

It may be simpler overall to avoid the caching completely if it's only for 40 people? Depends on the nature of the data and how costly it is to retrieve it.
 
only if the data is small
In this case, it is storing statistics which are purely integer.

We have two graphs which store weekly data so 14 integer sets which are unique to each user

Alongside that, we have another 20 integer sets that would be the same for everyone - so these are not unique

I think we're slowly getting out of a different topic - I may create another post talking strictly about performance, all comments made have been a big help and having a standalone discussion for this may help other new addon developers in looking to improve the performance of their addon as well.
 
Back
Top Bottom