How to track search response times in Laserfiche

asked on October 31, 2023

I am looking for a method to track the search response times for the searches that users are performing in Laserfiche.

The reason I need this is that, while the system overall performance is fine, some queries take a long time to run, and I suspect this is because some users don't use a proper search method (for example using a quick search with wildcards, where a metadata search would be more appropriate).

I hoped Audit Trail could help here, but Audit Trail reports only seem to log the Event Time (not sure if this is the start or end time), but not the Event Start AND the End Date, or its duration. Is there a way to extract that information from Laserfiche, either using Audit Trail or other methods ?

Thank you

0 0

replied on October 31, 2023

Hi Bogdan,

You're on the right track here. To save you some time though, wildcarded Quick Searches (especially the "Basic" searches that automatically include start and end wildcards) are almost certainly the main problem. At one point I spent weeks digging into the underlying SQL queries from these searches and found that "Basic" metadata quick searches ("*$searchTerm*") took around 1,000x more CPU time to execute than the exact value version ("$searchTerm"). Though that doesn't convert linearly to overall query execution time due to SQL multi-threading, it's still tens to hundreds of times slower. Too many such searches in a short time period has the potential to overload the SQL server and having a broader performance impact. Leading wildcards ("*$searchTerm") are the real performance killer; tail-end wildcards ("$searchTerm*") don't have nearly as much impact.

The best way I've found to address this is (a) building and deploying performance-optimized custom Quick Searches for your users, and (b) disabling the problematic "Basic" Quick Searches using a Web Client Custom Action script. You can read more about that solution and obtain the script code here:

Laserfiche Answers: Can Web Client 11 search bar defaults be set?

If your use case does legitimately involve searching certain fields with wildcards or fuzzy search, for example, being able to search just a last name value for a Full Name field, consider Indexing those fields and configuring the custom Quick Searches you build to be Indexed searches. Indexed searches are handled by the Laserfiche Full-Text Search (LFFTS) engine, which is optimized to handle those kinds of partial match searches. See the attached Advanced Search Syntax 10.3 white paper (info valid for Laserfiche 11) for details on how to specify an Indexed search.

Advanced Search Syntax 10.3.pdf (1.42 MB)

| Download

0 0

replied on October 31, 2023

Sam, I found your reply very interesting regarding how the repository searches work. I was wondering if you have any data regarding using advanced search syntax with [FieldName]="*" vs [FieldName]<>"" and if one is more efficient than the other?

0 0

replied on October 31, 2023

Blake,

Page 24 has these specific examples:

I have no idea if there is any performance difference between them for a "return all entries where $FieldName is not empty.

Outside of basic tests with the Laserfiche Windows Client and a stopwatch, you'd likely have to run both searches in a quiet test environment with SQL Profiler (or similar) running to check the underlying queries and their execution times. Results may vary between SQL Server versions and editions due to differences in SQL query plan generation.

0 0

replied on November 1, 2023

Hi Samuel,

Thank you so much for the quick answer.

My question here though was mainly if there is any way to track execution times for the queries (and perhaps other operations, such as document creation).

Currently, I can find in the Audit Trail the execution date and time, as well as the search syntax. This is great information, but ideally I would like to also find out, if possible, how much it took to the search to complete.

Thanks

0 0

Question

Question

How to track search response times in Laserfiche

Replies

Sign in to reply to this post.