Do you think this front-end posting app is too query-intensive?

• [email protected]

• March 17, 2020 at 11:07 pm

Hi

Sidenote: I’ve already asked this question with a support ticket but I’m also looking for an opinion from the community

Right now I’m thinking about creating a website/webapp based on WordPress and ACF Pro. It’s a front-end posting tool: each user will be able to create a new post with acf_form and then get the permalink of the post in return.

Each post is going to have a few basic field (5) and a repeater field which contains 6 fields.
Usually users are going to add about 20-40 repeater’s row.

To my understating (correct me if I’m wrong), this means that each and every time a post is created, since WordPress adresses each custom field saving at a time, there could be about 5+(6*30) = 185 queries which start as the user click the submit button on the form.

I’m not afraid for the actual post viewing – I’ll just add a caching system. What worries me is the amount of queries: is 180-200 queries a lot?. The thing is that I’ve always been a front-end developer and I don’t have that much knowledge server-side. What I’m worried about is what could happen if, per say, 1000 users (or 10k) click the submit button at the same time on this website hosted on a normal basic hosting (It’ll probably be Siteground GoGeek or something similar in the same range.

Is it actually scalable? Will it become super slow? Will it handle the pressure?

I’m sure that whatever the task there’s always been a server able to handle it but I’ll probably have a basic one. What I was wondering is if this scenario is, generally speaking, heavy/intensive for a common/average hosting.

Thank you

Bye

• John Huebner

• March 19, 2020 at 2:06 am

– #of queries for updating. I’m just giving you this for information. You actually have 6 fields including the repeater and 6 sub fields in the repeater. There are also this number of ACF field references. When inserting a new post this actually creates 2X this number of queries because WP does a query to see if the meta_key exists or has a value before it inserts the value. So what you actually have is (6*2)+(6*30*2)=372 postmeta queries.

I would definitely put an upper limit on the number of repeaters they can submit. Depending what these fields are 6 sub fields * 30 could time out on the submission. Text fields and other simple fields should not be an issue, but if you have 6 wysiwyg fields you might have an issue with only a single post being submitted depending on the amount of content being submitted.

– number of people hitting submit at the same time. I think that 1000 or more people all submitting a post at the same time would bring nearly any site on shared hosting down. I use VPS servers for some of our clients and I’d be worried about these going down. I’m sure we could beef these up to handle it if we needed to but then I’m not sure the clients would actually go for the additional costs. As far as shared hosting goes, depending on the data submitted, you’re going to see the server go down if this happens. You need to figure out what the likelihood of this happening is.

– post viewing, this should not be an issue. WP does a setup_postdata() when showing a post. This pulls all post meta data in a single query and puts it in the WP cache.

What you need to be careful of here is not the field content, but what you’re having ACF do with that field content. I will give you one example, image fields. When you return the image ID this will not create extra queries, however, returning an image array will create many additional queries to get all of the data associated with the attachments, some of which you may not need. If you have a lot of images you’re better of returning the ID and then only having WP get what you need instead of letting ACF do the work for you. The same can be said for post object and relationship type fields.

• [email protected]

• March 19, 2020 at 7:27 pm

Thanks! 🙂

#of queries for updating
Each repeater field has a radio selector and 5 text field (not wysiwyg)
There’s also no way for a user to add images or select images and I’m not querying images array and such.
I didn’t know that there would have been another query required to check if the value can be written – this worries me a bit.

What do you think should be the upper limit for the repeater field?

I imaging that (properly optimized) custom-coding a web app (not wordpress-dependent) would be more efficient and stable but how much?

Regarding the last point, I’m just showing each and every field value on the single post but it’s all basically just text

• John Huebner

• March 22, 2020 at 11:53 pm

I don’t think you’ll have a lot of problems with timing out with the type of data you’re using. You already have a upper limit on the number of rows that can be added. PHP has a setting for max_input_vars which is 1000, in your scenario you have 186, well below this threshold, so again, you shouldn’t have a problem here.

Custom coding an application could be more stable or not, really depends on how it’s coded and how it works.