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

Question

Question

Laserfiche Forms Overdue Prediction - SQL Pressure & Tuning

asked on January 12 Show version history

I've identified the following Stored Procedure in the SQL database for Laserfiche Forms that seems to be running very heavily:

  • GetCycleTimeOverduePrediction

 

This seems to be related to the Overdue Prediction function in Forms Reporting, introduced in Forms 10.3 -- See: What's New in Forms 10.3?

 

This process is running near-constantly in SQL and keeping steady pressure on the CPU. It's not a heavy load (utilizes about 10-15% of the CPU, in addition to anything else running), however it's constant.

 

I changed the name of the Stored Procedure to stop it from running for about an hour to gauge the results, which alleviated the CPU pressure by SQL, however it resulted in errors constantly in the Forms Event Logs (expected):

 

This tells me that process is running every 3 minutes, around the clock, at least. However, it seems more often than that, because looking in SQL I see the execution count for that Stored Procedure in the past 24 hours is 21,531.

 

I found this LF Answers post that provided a way to disable that function, however that doesn't exist in the current version  (Forms 12.0.2503.10378). I did, however, find that it seems to be enabled/disabled on a per-process basis in this version:

 

I browsed around within Forms (i.e. Process Design, Reporting, Administration, etc.) and haven't found any options displayed in the GUI for enabling/disabling that function.

 

My questions:

  • Can this only be disabled directly within the database (presumably by setting the "enable_predictions" value to "0")?
  • What are the implications of disabling it (does it only affect that reporting metric in Forms Reports, or are there other implications)?
  • Other than disabling it, are there any ways to tune it (i.e. limit the frequency with which it runs, scheduled runs, etc.)?

 

I'm just looking to gather more information and options on this process and these findings.

2 0

Replies

replied on January 12

The more concerning part of that message is that you are missing at least one stored procedure. So it's impossible to tell whether any performance tuning changes would have any effect. I would recommend opening a support case. 

0 0
replied on January 12

@████████ I'm not missing any Stored Procedures, I intentionally renamed that one, temporarily, to stop it from running. This allowed me to gauge the effect this one procedure was having on SQL (by seeing the change when it couldn't run) as well as see the frequency at which it was trying to run (by observing the errors in the Forms logs when it couldn't find it).

That was a temporary test, then I renamed it back to the correct name, so these errors aren't actively occurring now. The SQL pressure from how much this process is running around the clock continues.

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

Sign in to reply to this post.