Performance Improvements in 6.5

Improving performance from a developers view applies to various areas in farmerswife. There's no "one click" make it faster operation. So we've improved various areas:

Financial Reports

The following farmerswife (fw) Server-side performance improvements will typically have their greatest effect when running Financial Reports on BIG databases (= size of current45.efdb bigger than 150MB).

The built-in Financial Reports performance improvements are split in two parts:

1.  "Caching" (or pre-calculating and temporarily storing the results) of the most needed "Input" data during the start-up of the fw Server application. This can save time and reduce computing later. The "input data" is therefore "already ready" before any user has created a Financial Report.
   
   
2.  "Threading" of the actual fw-Client-FinancialReport-connection to the fw Server. This means, that the creation of the Financial Report no longer has an impact on the running fw Server session. It now only affects the user who is generating the Financial Report. This now no longer blocks the connection for everyone else, while the Financial Report is being created.
   

There are now these 3 new fw Client side Settings which allow to disable or enable this functionality in fw Client > Toolbox > Settings > Server Setup:

1. "Use Threading For Financial Reports":
   This is enabled by default.
   
   fw Server-side and technical details:
   The memory usage of the fw Server application during run-time will increase by around 30%.
   During the launch of the fw Server application, this will create within the fw Server's "system" folder a file called "init_worker_thread_flag".
   And on the fw Server's "Log" window this info will show this line:
   "Starting Up Worker Threads".
   
   The "init_worker_thread_flag" file gets removed again, when shutting down the fw Server application if there were no issues during runtime. Should this file be present during the launch of the fw Server application then this will cause this line to be stated on the fw Server's "Log" window:
   "Skipping Worker Thread Startup since it looks like previous startup failed".
   Then the next graceful shut-down of the fw Server application will then remove this file, for the "Use Threading For Financial Reports" to be active again on the next fw Server start.
   
   NOTE:
   This new functionality does NOT take effect when doing Financial Reports on a single Project and up to max. 3 selected Projects!
   In order for this new functionality to become active 4 or more Projects need to be selected to run a Financial Report on.
   
   ONLY if the following Setting "2) "Keep Thread Data Updated" is DISABLED (= not ticked), then when creating Financial Reports on 4 or more Projects, there will now be a yellow triangle "Warning" icon on the "Generate Report" button, which will shot this info on mouse-over:
   
   "The Report Data Being Used Was Last Refreshed:
   x-time Ago.
   Click To Refresh Now"
   
   "x-time" is based on the latest time the "Financial worker thread" was last updated.
   It is now the user's choice to generate the Financial Report based on the existing cached data by using the "Generate Report" button. Or to trigger an update to run the report on the latest data, simply by clicking on the yellow triangle Warning icon.
   
   
2.  "Keep Thread Data Updated".
   This is enabled by default.
   And this feature simply ensures that the new "Financial worker thread data" gets updated before each Financial Report. This causes the above mentioned Warning triangle icon to appear, since the worker thread data is up to date.
   
   
3. "Use Caching For Financial Reports":
   This is enabled by default.
   
   Technical details:
   This creates a NEW "caches.db3" SQLite-helper DB within the fw Server's "system" folder.
   
   

"Conflict Checker and Resolver"

The inbuilt "Conflict Checker and Resolver" is improved to save time on Booking operations on "big" databases, see details. The improvements have been benchmarked to save more than a minute when doing Booking operations on "big" databases ("big" = more than 10.000 Bookings).

farmerswife <> Cirkus integration

• Now, farmerswife will only query for Task changes since the last sync, instead of scanning all Tasks to see the changes.
• he first sync after a fw Server restart will always be a Full Sync.
• The button “Update Now” still triggers a Full Sync.
• We have also added specific Cirkus integration logs.
  To enable these debug logs, add the variable CIRKUS_LOGS_ENABLED with value 1 to the server settings.
  This will write to the file fw Server/system/customlog.cirkus.log, which can help with debugging of any integration issues.

"Web Shared Hourline Views" and "Dayplan Hourline Views"

We've improved the indexing process implemented for the "Web Shared Hourline Views" and "Dayplan Hourline Views". This was causing a "wait" of more than 6 seconds on databases containing a lot of "Saved Hourline Views", when just opening and closing e.g. the "Modify User" window, without doing any change. 

The Web Profile settings were also being affected, and these issues are fixed now.

"big" Bookings linked to Dispatches

A "big" Booking in farmerswife means that it contains many Objects (50+) and over a long duration (10+ days). 

farmerswife systems working in this style, our low-level performance improvements will make a substantial difference! 

Also note that a 50% to 60% files-size-decrease on the main database (current45.efdb) can take place during the upgrade; this itself is a performance improvement. 

Some examples: 

Opening a "big" Booking from the Long From > Projects tree > containing 500 Objects over 100 days, before took 30 seconds to open. 

Now, the same operation takes 2-3 seconds! 

1000% faster 

Depending on multiple factors ... adding 3 more Objects to an existing Dispatch > Check Out linked to a Booking over 100 days containing 50 Objects, took before this change 56 min. and more. 

Now, the same operation will take 7 to 9 seconds!