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

Discussion

Discussion

Possible Workflow Search Repository Bug

posted on September 17, 2014 Show version history

We've got a workflow that uses a Date Token Calculator to get a date that's two days ago and delete all documents that have a Modified Date before that date.

 

However, for some reason that causes our SQL load to go up to 80% for about 25 minutes. It looks like it's loading all 1.5 million Tocs into memory and then playing with them before finally returning results.

 

We're writing up a support case to send to our VAR. Can anybody replicate this? We're running Workflow 9.1.1.365

0 0
replied on September 17, 2014 Show version history

How big is the repository? Is this your basic folder path + modified date search? What are the specs for the SQL server?

 

Actually, ignore the questions above. Can you update to https://support.laserfiche.com/kb/1013512  and give it another try? If the search still takes a while, check the box labeled "exclude path column" in the Search Repository activity and try again.

0 0
replied on September 17, 2014

The repo is a little under 1.5 million Tocs. About 1.3 million of those are documents. The search string we're using is this:

{LF:Modified<"%(DateTokenCalculator_PurgeBefore)"} & {LF:LOOKIN="JacksonCounty\Assessment\Appraisal Jackets\Processing\Complete"}

The SQL server is 4 cores with 32GB of RAM.

0 0
replied on September 17, 2014

Ok, it'll probably be a day or so before I can get that through change control. What does that new option do?

0 0
replied on September 17, 2014

Between 9.0 and 9.1, Workflow switched to using RepositoryAccess instead of LFSO for connecting to Laserfiche to take advantage of the performance improvements that come with from having a .Net environment. There was a bug in earlier versions of RepositoryAccess where calculating security for the Entry Path column in the results listing was slower than expected for large results sets. The hotfix updates RA on the Workflow server with a fixed version. We've also added the UI option to speed up search even more when the entry path for each search results is not needed later in the workflow.

0 0
replied on September 17, 2014

Ok, we'll give it a try and report back. Thanks Miruna!

0 0
replied on September 17, 2014

If you do a search, it loads it all right away. then manipulates the results. To reduce this, you can tell the search to only return a select amount of entries and have this loop itself until it doesnt find any entries. That will lighten the load on SQL

0 0
replied on September 17, 2014

That still seems like a bug. It's supposed to restrict by folder, and that would be less than a thousand entries. I find it hard to believe that every time I do a search, Laserfiche is putting 25 minutes of load on SQL. We have lots of queries in various workflows that never produce any kind of issues like this.

 

In this case, removing the date component of the search eliminates the problem. Since I don't have any visibility into how Advanced Search Syntax translates into a SQL query, I can't tell exactly what it's doing, but I don't think it should be doing this.

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

Sign in to reply to this post.