You are viewing limited content. For full access, please sign in.

Question

Question

LFFTS or SQL Search for Template Field Searches

asked on October 24, 2018

Good Morning All,

I have what I believe to be a simple question that I can go into more detail if needed, but we have a client with a workflow that searches for documents based on a template, field and creation date.  The field being searched on isn't indexed, however a different field in the same template is indexed. 

Is there any reason this would utilize LFFTS instead of the SQL engine for the search processing?  This server has high LFFTS utilization and the client believes this workflow is impacting it, however I believe this would be a SQL search and would not impact the LFFTS utilization.  Just looking for thoughts and/or verification.

There are 2 nested search activities.  I have included a sanitized copy of the search routines below in case they are needed.  Due to the repository architecture, some folders had to be excluded from the search results, hence the long search routine.

 

({[TEMPLATE NAME]} & {LF:Name="*", Type="DB"} & {LF:Created>="%(SearchStartDate)", Created<="%(SearchEndDate)"} & {LF:LOOKIN="ROOT\Folder1"}) - ({LF:LOOKIN="ROOT\Folder1\Folder2"} | {LF:LOOKIN="ROOT\Folder1\Folder3"} | {LF:LOOKIN="ROOT\Folder1\Folder4"} | {LF:LOOKIN="ROOT\Folder1\Folder5"} | {LF:LOOKIN="ROOT\Folder1\Folder6"} | {LF:LOOKIN="ROOT\Folder1\Folder7"})


({[TEMPLATE NAME]:[Field 1]="%(From_1st_Search)"} & {LF:Name="*", Type="DB"} & {LF:Created>="%(SearchStartDate)", Created<="%(SearchEndDate)"} & {LF:LOOKIN="ROOT\Folder1"}) - ({LF:LOOKIN="ROOT\Folder1\Folder2"} | {LF:LOOKIN="ROOT\Folder1\Folder3"} | {LF:LOOKIN="ROOT\Folder1\Folder4"} | {LF:LOOKIN="ROOT\Folder1\Folder5"} | {LF:LOOKIN="ROOT\Folder1\Folder6"} | {LF:LOOKIN="ROOT\Folder1\Folder7"})

 

0 0

Answer

SELECTED ANSWER
replied on October 25, 2018

I don't see anything in these workflows that modifies the documents themselves, so it doesn't look like this would impact LFFTS.

1 0

Replies

replied on October 24, 2018

Hi Jason,

 

I'm with you on this one. My understanding is the LFFTS search is only used when performing a text search, which isn't included in any of your searches above.

 

Following this post for any further updates, as we have seen some spikes in LFFTS recently.

 

Cheers!

0 0
replied on October 24, 2018

Are you only seeing high LFFTS CPU utilization when this search runs in Workflow?

0 0
replied on October 24, 2018

Hi Miruna,

 

Because the workflow in question processes about 20,000 documents in a month's date range, it will take a few days for it to complete.  I will keep an eye on it, however this isn't the first time we have encountered high LFFTS CPU utilization at this client.  I will need to specifically monitor this when this next instance of the workflow completes.

0 0
replied on October 24, 2018

Right, but if this search is causing LFFTS' CPU spike, that should only happen while the search activity is running. Once Workflow moves into processing those documents, any LFFTS activity should be over.

 

Side track: I'm assuming you're processing 20,000 in a For Each Entry activity. Have you considered moving the activities contained in For Each Entry to their own workflow that you invoke? That way you'd be taking advantage of Workflow's parallel execution of instances and probably get through the documents faster.

0 0
replied on October 24, 2018

On second thought, if you're processing that many documents with indexed fields, there's also a possibility that LFFTS is reorganizing the catalog because of all the changes.

On your original question, this is a SQL, not LFFTS, search.

If you're running performance counters, you might be able to correlate the CPU spike with the time the Search Repository activity ran or see the spike starts as Workflow moves into processing the documents.

0 0
replied on October 25, 2018 Show version history

Thank you for the thoughts Miruna and Doug.  Based on those thoughts, do you think that there could be some external impact to the LFFTS because the documents being processed contain fields that are indexed (even though I'm not acting on those fields).  If so, I assume if I removed the indexed flag on that field, it would be an easy way to validate the results by monitoring the activity of the LFFTS before the workflow runs and while it's running.

Also, you are correct.  The 2nd search activity processes about 20,000 documents each time it runs.  I have attached screenshots (with sensitive info redacted) that show the main workflow and the invoked workflow for the processing loop.

Workflow Part 1.jpg
Workflow Part 2 - Invoked Workflow.jpg
0 0
SELECTED ANSWER
replied on October 25, 2018

I don't see anything in these workflows that modifies the documents themselves, so it doesn't look like this would impact LFFTS.

1 0
replied on October 25, 2018

Many Thanks Miruna.  As always, I appreciate the feedback.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.