We are seeing some pretty significant search times with what feels to be a pretty straight forward search against 5 fields in our repository.  For example, the same search can be repeated and generally take between 15-20 seconds to display the ~200 results.  Running "Search Entry Names" and "Search Fields" with the same input value only takes about a second or two longer on average. 

To give you a rough idea of our repository - we're between 1.2-1.3 million docs .  Recent changes of significance to the repository in the last month include importing around 100k tax forms and upgrading from 10.2 to 10.3.  I did start to clue into the longer searches prior to those events.

The search being used is a quick search from Laserfiche Client 10.3 which searches against:

• Entry name as a wildcard or 
• Account name as a wildcard or
• 3 identifiers as an exact search (account number, asset number, workflow id)

When I created and deployed this quick search to our user base last June the generic search entry names and search fields were generally running in the 5-10 second range with an occasional one which would run to 20 seconds.  The quicksearch at the time we deployed it last June cut those times in about half 3-5 seconds.  The particular search used in the testing is returning around 200 documents and I don't have any of the calculated columns referenced in the search performance materials.  The result columns are a collection of a handful of system fields - name, size, page count, template, dates, entry id, and custom fields - the few listed above and one or two more.  In total about 12 columns.  We have setup a SQL profiler and see about 3 seconds worth of DB queries for the search.

I do see the same search performance when running the search in LF Client on the server itself.  I performed that test to rule out networking hops, firewalls and anti-virus software which run on client PCs.

Any recommendations on methods to further diagnose or settings to investigate and modify are appreciated.