Data Volumes and Impact on Performance

Data Volumes and Impact on Performance

Data Volumes

This article explains how data volumes can influence performance and user experience. Apart from technical Firebird Database settings, Configuration settings within Ostendo can also affect performance. As sites run Ostendo and Freeway over time, data volumes should be managed. Whilst initially a site may have not experienced performance issues in the early days of an implementation, as time goes on, their data volumes should be monitored and configuration settings potentially amended to suit their environment.

  • Symptom:
    • List Grids Slow to load (Orders, Payments, Batch Invoicing): Large volumes of Closed Orders, Fully Applied Payments and Fully Paid Invoices can affect the speed Ostendo takes to load the Grid when Grid options Filtering & Sorting and "Included Closed", etc.. are selected by the user on a List Grid. It should be noted, when Filtering and Sorting is turned on, Ostendo has to load 'all' relevant records into memory (not just one screen full) before it can display the Grid.
    • Slow search results from a List Grid
  • Recommendation:
    • If a site experiences this, we suggest you consider turning on Dynamic Archive Days (File->System Settings->Environment Settings Tab). This parameter (No of days) filters out Closed Orders, Fully Applied Payments and Fully Paid Invoices older than 'today' less the Dynamic Archive Days setting. The number of days you specify may well be different from site to site. There is no 'one fits all approach'. Typically though most don't need to refer to closed transactions older than 2 years. You should note, this doesn't actually remove data, but filters it out for everyday operations. Data is still available for reporting purposes.
    • Consider each Users Grid Option settings:
      • Save List Filter Conditions and Auto Activate Filtering & Sorting: These settings are retained when a user turns on Filtering and Sorting. If these features are NOT selected the screen is not filtered and the response will be quicker. These user settings are found under (File->System Configuration->User Security & Options->Options Tab-> Grid Options)
    • Consider amending the status of records, which can influence the load speed of a Grid. eg: You may have 5000 items, however only a small number are ever used. Consider marking un-necessary items as Obsolete. Same goes for Customers, Suppliers, Descriptors etc being marked as InActive if no longer in use.
    • Review each user Grid Customisations. Do they really need to show all the fields they have set?. Remember, the more data to be shown the slower the screen will take to load into memory.
    • Check whether Advanced searching is turned on (File->System Configuration->System Settings->Environment Settings tab). This form of searching allows a deeper search of data. This is extremely useful in some environments however can cause the searching to slow down and produce numerous search results. Consider turning this off only if it is not required by the site.
  • Symptom:
    • Slow Screen Load when launching an Ostendo option
  • Recommendation:
    • Check if Activate Screen Logging is turned on (File->System Configuration->System Settings-Environment Settings tab). This function is useful to determine what screens / reports etc.. each user launches. If this function is turned on, each time they access a screen, report, workflow etc, a record is written to the SCREENLOGGING table. This information can be helpful when a site is being implemented, however can cause an overhead on the system if left on. It is suggested that this table is purged of unnecessary records periodically if this feature is in use. A simple SQL statement can be used for this.
    • Check if Audit Logging is turned on (File->System Configuration->Audit Logging). If this is in use, each time a field value is potentially Inserted, Updated or Deleted, Ostendo will write a record to the AUDITLOGGING table. If this is in use, ensure that it is still required and consider purging unnecessary records periodically.
    • Check if Notification Logging is turned on (File->System Configuration->Notification Logging). If this is in use, each time a field value is potentially Inserted, Updated or Deleted, Ostendo will write a record to the NOTIFICATIONLOGGING table. If this is in use, ensure that it is still required and consider purging unnecessary records periodically.
  • Symptom:
    • General performance and occasional Deadlock Conflicts may occur
  • Recommendation:
    • When a financial transaction is written to the Financial tables in Ostendo, Journal records are also written to the Journal tables. These journals are used to post to modern Accounting Software (eg: Xero, MYOB Live etc..) Journal record volumes can quickly become huge, and affect performance and also contribute to Deadlock Conflicts on some occasions. Therefore we recommend that regular Archiving Journal Data be periodically performed. This download link has all the necessary information to set this up and maintain these tables. http://www.ostendo.info/downloads/ostendo/JournalArchiving.zip
    • If the general performance of a screen becomes an issue, we recommend you investigate any Custom Scripts: (specifically, Screen Data Scripts). These can affect performance or even generate database messages if badly written. (File->Scripting Configuration->Screen Data Scripts)
    • Custom Triggers or Procedures within a Database can also dramatically affect performance and behaviour of a database. These are not so easy to find but can generally be found by connecting a copy of the database to a third party utility eg: IB Expert. If you are unsure of this, it is suggested you contact a Developer Partner for assistance to determine if any custom Triggers or Store Procedure exist in the database.
  • Symptom:
    • Slow generation of the Inventory Replenishment routine: This routine is a complex routine in itself and therefore must determine data from multiple sources within the database. Therefore it can genuinely take sometime to generate, especially, if you are including the 'Multi-Level' Explosion' option.
  • Recommendation:
    • Unless explicitly required, we recommend the Replenishment Horizon be set to 'Weekly' rather than 'Daily'. This achieves the same results, however the Projected requirements are summarised in Weeks rather than by Day. Because of this there is less data involved when generating the Replenishment. (Requirements->Settings-> Requirement Rules)
    • Consider reducing the Replenishment Horizon, as this will also influence the volumes of Projected Requirements records for each item. (Of course in some environments, this may not be practical). 
  • Symptom:
    • Assignment Board slow to load: The Assignment Board is loaded based upon the Assignment Profile. (Requirements->Assignment Profiles). That profile allows you to control the following:
  • Recommendation
    • These settings can potentially affect performance: 
      • Horizon - Days Back (recommended no more than 30 days)
      • Horizon - Days Forward (recommended no more than 30 days)
      • Auto Refresh Rate (set this as high as practical)
      • Check for Warning on Load (consider leaving this turned off and allowing the user to manually run this from the Assignment Board if / when required)
      • Conditioning of Data (eg: Include / Exclude Departments / Employees etc..) Consider limiting the volumes of Employees or Departments etc.. maybe create one Assignment Board Profile for each Department.
  • Symptom:
    • Slow launch of an Inquiry, Pivot, Analysis View or running a report: Check the Queries specified in the Report & View Developer for the Inquiry, Report etc.. concerned.
  • Recommendation
    • Ensure each query is only calling the fields it needs to call. Typically when people write queries for reports etc, they select all fields, and end up only using a few. The less fields to be returned in a query will always be the most efficient.


  • Symptom:
    • Freeway slow to synchronise: Primarily the speed of this is controlled either by the Internet connection or by the volume of data.
  • Recommendation
    • The quality of internet connection is out of our control, however there are things you maybe able to do to ensure only the relevant data is sent to Freeway. These include reviewing the following:
      • If a Company Logo has been specified against the System Settings, that logo will always be sent to the device (even if it is not used on any Freeway Reports). Ensure this logo is no more that 25 Kb in size (Optimal Size is 25Kb however if the image is greater than 100kb the image will be excluded from Freeway)
      • Employee Mobility Settings:
        • Ensure only relevant Selections are set for each Employee (eg: Jobs, Customer, Suppliers etc..)
        • Avoid using a selection range 'All Open 'Jobs', 'Assemblies' or 'Deliveries' unless there are small data volumes or this is the most practical manner of deploying work to Freeway (ie: rather than using the Assignment Board). Think of how many records maybe returned if you specify this without a Restriction Condition.
        • Make use of Restriction Conditions to limit the volumes of records being sent to the device.
        • Consider how many Items and Descriptors are in the sites database. We recommend using either a Restricted Materials List, or an Items Restriction Condition if possible. NB: Obsolete Items and InActive Descriptors are never sent to Freeway by default.
        • Check Job, Assemblies and Delivery Horizon days settings are not set too far forward for the employee
        • Check Mobility Rules setting Assigned Transfer Horizon Days is not set too far forward for the site.
        • Check The number of days forward to display ToDo activities setting is relevant to the employee
        • Check Job, Assemblies and Delivery Include Non-Finished Assignment a number of days back setting is relevant to the employee
        • If using Stock Counts in Freeway, ensure the following Mobility rules are not set too high. (Blank values  = 50. A maximum of 200 is allowed however in some environments this should be left as 50 or blank)
          • No. of Remaining Count Lines to Display
          • No. of Counted Count Lines to Display
        • Backgrounds & Buttons: Ensure no images are loaded against the Employee that are greater than 25Kb in size. (Optimal Size is 25Kb however if the image is greater than 100kb the image will be excluded from Freeway)
        • If Mobility Images (Descriptor or Item) are used, ensure no image is greater than 25Kb in size. (Optimal Size is 25Kb however if the image is greater than 100kb the image will be excluded from Freeway)

As you can see there are numerous settings within Ostendo that can affect performance. Our recommendation would be to regularly review these for each site to ensure current configuration settings are still applicable to that site and their data volumes
    • Related Articles

    • 26/11/2024 - Data Volumes

      Data Volumes This article explains how data volumes can influence performance and user experience. Apart from technical Firebird Database settings, Configuration settings within Ostendo can also affect performance. As sites run Ostendo and Freeway ...
    • Improving Performance of Opening Lists

      As a database gets larger, the opening List grids can take longer to load, when 'Include Closed' Orders, 'Include Updated Status' or 'Include Fully Paid' is turned on along with Filtering and Sorting from the Grid options. This is because in order to ...
    • Database Sweep Interval Setting To Improve Performance

      Amending the Database Sweep Interval Setting Overview: On some large databases, performance issues maybe experienced due to the database Sweep Interval setting being set at a higher level than need be. By default the Sweep Interval setting is set to ...
    • Firebird Restart to improve performance and remove External Users

      Firebird Stop / Start process Large Ostendo sites running 20+ users should stop and re-start Firebird on a regular basis to ensure performance is maintained. The major issue to automating this process in the past has been the worry that users may ...
    • Archiving Historical Journal Records

      When we post to Accounting products like MYOB AR Live, Xero, QBO and Sage Evolution, we post from 4 tables in Ostendo. JOURNALHEADER (these records will be posted as General Ledger Journals in the Accounting Software) JOURNALLINES (each journal may ...