Our website has large amounts of data, 12k+ events, 5k+ organizers and 14k+ venues. We believe that because of the amount of data and the way you have programmed certain aspects of your plugin we are experiencing extremely long load times, specifically on the edit event page. On that page, one of your methods in your plugin is loading all 5k+ organizers and 14k+ venues into two dropdowns on the page.<\/p>\n
Through various methods of testing, including looking at NewRelic data for specific functions that are taking a long time to process and by incrementally eliminating data from our database and running performance tests in the browser, we have narrowed down this issue to one feature \/ function in your plugin: As a potential fix to this problem, I think that moving the loading of this data to AJAX and only loading it in chucks or based on the query being typed in (similar to what we are doing on our front end: http:\/\/g.recordit.co\/Z61RjaDK4u.gif which can be tested here: https:\/\/hikeitbaby.com\/find-a-hike\/submit-a-hike\/add) would greatly improve the performance of this page. You would then only want to echo a single item or two into the select lists from the method mentioned previously, just the one that is currently selected…<\/p>\n I see that other customers have encountered this and similar issues: https:\/\/theeventscalendar.com\/support\/forums\/topic\/query-is-too-long-for-organizers-info-and-venue-info-methods\/ We sometimes have multiple volunteers working on reviewing and approving our publicly submitted event data and when they are all online trying to edit and publish events (“hikes” in our case) and the edit page they are trying to use takes 50-60+s for every load, it not only takes them a lot of time and is frustrating, but also causes our site to slow down, the result of which is 502 errors caused by WP Engine killing off various processes (on the front and back end). 90% of the time, the location and\/or organizer doesn’t even change, so the fact that data is being loaded every time is completely unnecessary and only needs to be available when someone clicks on that dropdown. And even then, they will be searching for a specific venue which could be queried for over AJAX.<\/p>\n","protected":false},"template":"","class_list":["post-1170612","topic","type-topic","status-closed","hentry"],"yoast_head":"\nLinked_Posts::saved_linked_post_dropdown()<\/code>. This method echo<\/code>s two <select> lists with <options> for all the 19k+ organizers and venues in our database. Because of the large amount of data, this seems to take 40-50s in our current case (just for this task). You can see in the attached image that by incrementally deleting data from our database that load times improve. I even tried directly modifying the plugin to just echo an empty <select> list at the very top of the function (and return immediately after) to bypass the rest of the processing (which resulted in the fastest load times).<\/p>\n
\nbut your suggestions to turn off the WPE_GOVERNOR only help with the actual execution of long queries and do not address the actual performance issues of loading tens of thousands of entries onto a page… Do you have any plans to address these types of concerns so that your plugin is more scalable and won’t impact the performance of the rest of the site?<\/p>\n