Child pages
  • Performance Related Configuration Settings
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

The following settings have a significant impact on Flux performance. Setting them to these recommendations optimizes the engine for performance, at the expense of functionality, loss of history, or logging details.

  • Using a runtime configuration file impacts where concurrency is set for a Flux engine. 
    • If a runtime configuration file is defined in the engine configuration, concurrency is set using CONCURRENCY_THROTTLE in the runtime configuration file. 
    • If no runtime configuration file is configured, concurrency is set using CONCURRENCY_LEVEL in the engine configuration file. 
    • If a runtime configuration file is being used, and no CONCURRENCY_THROTTLE is set within that runtime configuration file, the engine will run with it's concurrency set to 10 regardless of what the engine's CONCURRENCY_LEVEL is set to.
  • Set SERVER=false (which disables the Flux engine's REST API, Flux agents, and the operations console web application)
  • Set INTERNAL_LOGGER_LEVEL=INFO
  • Make sure - if using the default Flux internal logger - that it is set as follows: logger_types.0=INTERNAL_ASYNCHRONOUS. Having it set to INTERNAL_SYNCHRONOUS will make blocking-writes to the log, which is useful in developing and debugging workflows but not in production.
  • Set CLUSTER_NETWORKING_ENABLED=false (but note that this disables agents and disables the bytes sent/received displayed on the console while file transfers are executing).
  • Set CACHE_TYPE=NONE to stop using the cache for workflows.
  • Minimize or eliminate the use of prescripts and postscripts since these involve the interactive execution of code within workflows and reduce performance
  • Set RUN_HISTORY_ENABLED=false to turn off run history data collection
  • Set FLOW_CHART_DEADLINES_ENABLED=false to turn off checking for flowchart deadlines
  • Set AUDIT_TRAIL_FILTER.0= (and no other audit trail filters are present or all others are commented out)

Specific to SQL Server Installations:

Using the connection string parameter selectMethod=cursor was required in old releases of SQL Server. In more recent versions, it is only needed if large result sets are being returned back to the client (generally more than 100 records at a time), and only if the client has insufficient memory to handle the returned result set. If this is turned on, the server returns results at 100 rows per call but at the expense of server performance. In testing Flux, the performance hit seems to be around 35-40% for Puts by themselves as illustrated in the SelectMethod.png attachment below. Puts and execution is also improved - as seen in SelectMethod 2.png. Removing this parameter from the SQL Server connection string should provide some significant performance gain.

Per the Microsoft website at http://msdn.microsoft.com/en-us/library/ms378988.aspx :

'If this property is set to "cursor," a database cursor is created for each query created on the connection for TYPE_FORWARD_ONLY and CONCUR_READ_ONLY cursors. This property is typically required only if the application generates very large result sets that cannot be fully contained in client memory. When this property is set to "cursor," only a limited number of result set rows are retained in client memory. The default behavior is that all result set rows are retained in client memory. This behavior provides the fastest performance when the application is processing all rows.'

 

  • No labels