<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">We’ve had some issues with certain searches in the staff interface ( v2.6.0 ) and I wonder if anyone else has observed this. </div><div class=""><br class=""></div><div class="">We were getting proxy errors on some searches from the Staff web app. </div><div class="">We are adjusting the proxy timeouts in apache to get around this, however, finding that some searches really do take too long. </div><div class="">I’ve found a pattern in the failing searches and I think I’ve discovered two separate issues. </div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">First of all — the problem isn’t actually with the SOLR search, which returns quickly, </div><div class="">But with formatting the results — specifically the ‘Found In’ column where it needs to collect the ancestors titles to show the items place in the hierarchy.</div><div class="">Searches that have only top level resources in the first page of results return quickly as there is no ancestors to display.</div><div class="">Searches with archival_objects in results take longer. Top_container results appear to be the slowest, as there may be multiple resources in the list. </div><div class=""><br class=""></div><div class="">Rendering _context.html.erb for top_containers maybe 5-10x slower worst case than rendering top level resources:</div><div class=""><br class=""></div><div class=""><a href="https://github.com/archivesspace/archivesspace/blob/master/frontend/app/views/search/_context.html.erb" class="">https://github.com/archivesspace/archivesspace/blob/master/frontend/app/views/search/_context.html.erb</a></div><div class=""><br class=""></div><div class="">I haven’t seen a similar issue with PUI searches which seem to use only SOLR, while the staff webapp makes multiple backend API calls that are probably doing SQL access. </div><div class="">( Which leads me to think that this ancestor field ought to be cached in SOLR for the Staff search to avoid these worst case search events. )</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">The 2nd issue seems to be that our production server is significantly slower at this than test machines. </div><div class="">This appears to be a greater factor than can be explained by the greater load on production server.</div><div class="">I suspect, but haven’t yet proven, that the difference is due to using a central MySql server for production but using a local MySql server on test machines. </div><div class=""><br class=""></div><div class="">This seems to add a similar order of magnitude slowdown to search results. </div><div class="">So maybe worst case difference = 10 * 10 = 100x slower. But not seeing that large a difference on average. </div><div class=""><br class=""></div><div class="">These are mostly guesses from observing logs — I’m adding some instrumentation to make a more definitive diagnosis. </div><div class=""><br class=""></div><div class="">— Steve Majewski</div><div class=""><br class=""></div></body></html>