Skip Navigation

[Resolved] Slow performance when adding new post relationship in back end

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.

This topic contains 7 replies, has 2 voices.

Last updated by Brad 4 years, 9 months ago.

Assigned support staff: Luo Yang.


Hi Luo,

This is a follow-up to the successful resolution of Thank you again for that great resolution.

The many-to-many relationship is working properly both in the creation and the display of the desired custom post type relationships. However, as I have been adding new post relationships from the back end in the "Post Relationship" area, I noticed that performance seems a bit slow.

First, the subjective element of the slowness is that it seems to take longer than expected to populate the new field based on typing at least one character. By the time the jquery result comes back, I can type the correct value manually. Is this normal speed or is there some aspect of my specific site that is causing things to be slower than normal?

Second, the objective element of the slowness is that when I add a new post relationship item as described above, EACH and EVERY previously entered item is also updated by jquery. These field updates seem unnecessary. Why update the field values that have not changed? Again, is this normal behavior, or something wrong with my specific site?

What method of creating and editing post relationships will provide the best user experience? Would using CRED on the front end provide a faster process that will allow the user to rapidly create post relationships from a relatively static set of CPTs? It seems that when the list of possible choices is relatively small, it would be more efficient to populate ONCE the list of options and then allow the user to check or uncheck the desired options.

I will gladly read up on using CRED or other Toolset tools to improve the user experience but would appreciate your direction as to the best approach and where to start reading.



Luo Yang

Languages: English (English ) Chinese (Simplified) (简体中文 )

Timezone: Asia/Hong_Kong (GMT+08:00)

Dear Brad,

Could you point out the problem URL, where I can see the problem:
I have been adding new post relationships from the back end in the "Post Relationship" area, I noticed that performance seems a bit slow.

And you are using 32 custom plugins and custom theme in your own website, I suggest you try increase PHP memory limitation in your website, more help:
Increasing memory allocated to PHP


Hi Luo, have a look at hidden link. This is the URL to edit the "Test" Unit. Under the "Post Relationship, Assignments" section, add some new Assignments. Notice the behavior of the existing Officers fields as you add a new one.

The memory_limit is already at 1024M. I may need to take a look at query_cache_size and query_cache_limit. One of the plugins on the site is Query Monitor. On a back end page, it shows a lot of performance information, including the information I just mentioned. Look for the red bar at the top of the page, hover over it, then choose Environment to see this information.

I'm sure general performance can be improved with some tweaks, but my main objective is to make sure there is no fundamental problem or conflict that is affecting the speed of adding Assignments to Units.

Also, do you see a better way to improve the user experience, especially regarding speed, when assigning several officers to a unit? Does CRED give a way to do this without so many queries back and forth from the browser?

Thanks again for your help.


FYI, below are my memory settings:

define('WP_MEMORY_LIMIT', '768M');
define('WP_MAX_MEMORY_LIMIT', '1024M');

This will limit memory to 768MB in the front end but will allow 1024MB in the admin. 256MB is the default for the WordPress admin, unaffected by WP_MEMORY_LIMIT, only by WP_MAX_MEMORY_LIMIT.

The server has 16GB RAM and only a few websites with very light traffic, so shouldn't be taxed too heavily.


Luo Yang

Languages: English (English ) Chinese (Simplified) (简体中文 )

Timezone: Asia/Hong_Kong (GMT+08:00)

Thanks for the details, I don't think it will be better to setup CRED forms, since you are using lots of many-to-many relationships in post type relationships, and I can see you have already installed debug plugins in your website, then I tried these in your test site:
1) Update Types plugin to the latest version 1.8.10,
2) Deactivate other plugins and switch to wordpress default theme(2015), it seems there isn't performance any more,
3) then I activate other plugins and switch back to theme (Suffu-scion), the query monitor shows:
2.63 second in load time, I think it is reasonable time to run such a website with 32 plugins. please test again, check if it is fixed or not.


Thanks, Luo. Since that is the performance that you would expect, I won't worry about finding a non-existent problem.

Since the menus and widgets didn't survive the round trip in theme selection, I reloaded the site from a backup of the production site. It was time to update the old data on the development site anyway. I recreated your user account, so you should still be able to access the site, but I think that won't be necessary again for now.

I appreciate your help and efforts in looking into this.

Before I mark this issue resolved, I have one further request. Could you pass along a request to the development team to try to find another option for the user interface of adding post relationships? It seems there must be a more efficient interface for adding a number of post relationship instances at one time. Perhaps a scrolling listbox from which the user could select multiple items before saving the selections. This would make it easier for the user to "see and select" rather than "remember and type." It would also reduce the number of updates required to be sent to the server.

Thanks again.


Luo Yang

Languages: English (English ) Chinese (Simplified) (简体中文 )

Timezone: Asia/Hong_Kong (GMT+08:00)

Thanks for the feedback, I put it into our to-do list as a feature request, our developers will take care of it, but there isn't ETA for it.


Thanks, Luo. I'll mark this issue resolved now.

Your excellent support is always appreciated.