Skip Navigation

[Resolved] CRED Form Submission taking a lot of time

This support ticket is created 2 years, 6 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 - - 9:00 – 13:00
14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 - - 14:00 – 18:00

Supporter timezone: Africa/Casablanca (GMT+00:00)

This topic contains 7 replies, has 3 voices.

Last updated by himanshuS 2 years, 6 months ago.

Assisted by: Jamal.

Author
Posts
#2174461

I have been submitting forms with CRED for a while now and nothing has taken more than 2 seconds to submit. If at all there is a delay, it is because of redirection to a new page - which is fine.

But now I have a major issue that CRED form submission is taking almost 14 seconds for any new post. I have tried this for two post types and the issue exists.

This is not a site-wide server issue because many other high-intensity activities such as dashboard load are working as expected.

The browser inspection functionality just shows that ?_tt took 14 seconds.

Screenshots -
hidden link
hidden link

What could be causing this issue?

#2175375

Hello, it's hard to say offhand what could be causing this. It sounds like you're saying you submit a Form to create some post, and a redirect is triggered after the Form submission. First I would run the standard troubleshooting steps:
-- Activate the default Twenty Twenty One Theme
-- Deactivate all custom code snippets not immediately necessary for form submission
-- Deactivate all 3rd-party plugins except Toolset
-- Test again.
-- If there is a significant difference in processing time, reactivate components one by one, retesting each time until the problem returns. Try to isolate one or two components responsible for the conflict and we can investigate further.

- Is any custom code involved - Forms API hooks, save_post, update_post, Post Relationships APIs etc, that creates new posts or connects posts with post relationships? You could test iteratively removing or commenting out chunks of code to see if you've got a bottleneck somewhere.

- Are server logs running? Anything obvious there that would account for extra processing time?

- Is there a similar delay when publishing similar posts in wp-admin?

#2176621

- Is there a similar delay when publishing similar posts in wp-admin?
No. The issue is with Toolset.

- Are server logs running? Anything obvious there that would account for extra processing time?
Yes and No.

Is any custom code involved - Forms API hooks, save_post, update_post, Post Relationships APIs etc, that creates new posts or connects posts with post relationships? You could test iteratively removing or commenting out chunks of code to see if you've got a bottleneck somewhere.
The issue seems to exist for couple of post types. So I am looking at custom code that might impact them. Will keep you posted.

#2177935

I'll stand by, for your update, thanks!

#2179859

Chris,

I have looked at all the custom code snippets related to this post type. I disabled them one by one (4 of them) but there was no effect on the form execution speed. The speed generally stays around 9.5 seconds!

This is a very important step in the user journey and I am wondering if there is a way to drill down further by knowing all the processes it takes to execute this form submission and then find the process that is slowing things down.

I have a staging site that I can give you access to if that would help.

Regards,
Himanshu

#2180051

Jamal
Supporter

Languages: English (English ) French (Français )

Timezone: Africa/Casablanca (GMT+00:00)

Hello Himanshu! Christian won't be available. If you don't mind, I'll continue with you on this ticket.

Your next reply will be private to let you share credentials safely.

From the screenshot, I assume it is a form inside the"project-prompt1" post type, right?

Please provide any additional information that could help. Maybe about the user flow, or anything you think is relevant.

#2181087

Jamal
Supporter

Languages: English (English ) French (Français )

Timezone: Africa/Casablanca (GMT+00:00)

Thank you for the credentials. Honestly, It would be hard for me to debug this issue. First, it takes me around 40s to fully load the form's page hidden link
55s in case of a validation error, and 73s for complete form submit(which reveals a perf issue)

Second, because I can't use the Query Monitor plugin to investigate the queries that take too much time. I installed the plugin and it causes an issue that makes the page blank. Probably because of a compatibility conflict or a server resource limit.

To check for performance issues, we'll need the Query Monitor plugin active. Please deactivate all other plugins and check if the Query Monitor plugin will work.

At the same time, we'll need the admin bar to be visible to see the results of Query Monitor. The admin bar is not active now, and I don't know what makes it inactive.

Please perform the following test and share the results with me here:
1. With a default theme and ONLY Toolset plugins, and the custom code snippets DEACTIVATED.
2. With a default theme and ONLY Toolset plugins, and the custom code snippets ACTIVATED.
3. With your theme, and ONLY Toolset plugins, and the custom code snippets ACTIVATED.

If you can report the results in this format, it will make it easy to read for us:
************************************************
1. Default theme + ONLY Toolset plugins +- Custom code snippets.
************************************************
Page generation time: xxx
Peak memory usage: xxx
Database query time: xxx
Number of queries:

Please:
- Submit the form at each test.
- Pay attention to the Query Monitor results:
---number of queries
---the caller
---the load time of single queries.

#2185307

My issue is resolved now. Thank you!

It was the SG optimizer plugin that was slowing things down.

This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.