Internal Configuration Settings in Flogo Enterprise Application

Flogo Enterprise is so great platforms to build your microservices and Out of the box, you’re going to reach an incredible performance number.

But, even with that, we’re working in a world where each milliseconds count and each memory MB count so it is important to know the tools that we have in our hands to tune at a finer-grained level our Flogo Enterprise application.

As you already know, Flogo is built in top of Go programing language, so we are going to differentiate the parameters that belong to the programing language itself, then other parameters that are Flogo specifics.

All these parameters have to be defined as environment variables, so the way to apply these are going to rely on how you set environment variables in your own target platform (Windows, Linux, OSX, Docker, etc…)

Flogo OSS Specific Parameters

You can check all the parameters and it is default values at the Flogo documentation:

Performance Related Settings

  • FLOGO_LOG_LEVEL: Allows to set at start-up level the log level you want to use for the application execution. The default value is set to “INFO” and it can be increased to DEBUG to do some additional troubleshooting or analysis and set to “WARN” or “ERROR” for production applications that need most performance avoiding printing additional traces.
  • FLOGO_RUNNER_TYPE: Allows to set at the start-up level the type of the runner and the default value is POOLED.
  • FLOGO_RUNNER_WORKERS: Allows to set at the start-up level the number of Flogo workers that are going to be executing logic. The default value is 5 and can be increased when you’re running on powerful hardware that has better parallelism capabilities.
  • FLOGO_RUNNER_QUEUE: Allows to set up at the start-up level the size of the runner queue that is going to keep in memory the requests that are going to be handled by the workers. The default value is 50 and when the number is high it will be also high the memory consumption but the access form the workers to the task will be faster.

Other Settings

  • FLOGO_CONFIG_PATH: Sets the path of the config JSON file that is going to be used to run the application in case it is not embedded in the binary itself. The default value is flogo.json
  • FLOGO_ENGINE_STOP_ON_ERROR: Set the behavior of the engine when an internal error occurs. By default is set to true and means that engine will stop as soon as the error occurs.
  • FLOGO_APP_PROP_RESOLVERS: Set how application properties are going to be gathered for the application to be used. The value is property resolver to use at runtime. By default is None and additional information is included in application properties documentation section.
  • FLOGO_LOG_DTFORMAT: Set how the dates are going to be displayed in the log traces. The default value is “2006–01–02 15:04:05.000”.

Flogo Enterprise Specific Parameters

Even when all the Project Flogo properties are supported by Flogo Enterprise, the enterprise version includes additional properties that can be used to set additional behaviors of the engine.

FLOGO_HTTP_SERVICE_ PORT: This property set the port where the internal endpoints will be hosted. This internal endpoint is used for healthcheck endpoint as well as metrics exposition and any other internal access that is provided by the engine.

FLOGO_LOG_FORMAT: This property allows us to define the notation format for our log traces. TEXT is the default value but we can use JSON to make our traces to be generated in JSON, for example, to be included in some kind of logging ingestion platform

Go Programing Language Specific Parameters

  • GOMAXPROCS: Limits the number of operating system threads that can execute user-level Go code simultaneously. There is no limit to the number of threads that can be blocked in system calls on behalf of Go code; those do not count against the GOMAXPROCS limit.
  • GOTRACEBACK: Controls the amount of output generated when a Go program fails due to an unrecovered panic or an unexpected runtime condition. By default, a failure prints a stack trace for the current goroutine, eliding functions internal to the run-time system and then exits with exit code 2. The failure prints stack traces for all goroutines if there is no current goroutine or the failure is internal to the run-time. GOTRACEBACK=none omits the goroutine stack traces entirely. GOTRACEBACK=single (the default) behaves as described above. GOTRACEBACK=all adds stack traces for all user-created goroutines. GOTRACEBACK=system is like “all” but adds stack frames for run-time functions and shows goroutines created internally by the run-time. GOTRACEBACK=crash is like “system” but crashes in an operating system-specific manner instead of exiting.
  • GOGC: Sets the initial garbage collection target percentage. A collection is triggered when the ratio of freshly allocated data to live data remaining after the previous collection reaches this percentage. The default is GOGC=100. Setting GOGC=off disables the garbage collector entirely.

PSG Senior Architect at TIBCO Software with a focus on Cloud Development, Event Processing and Enterprise Integration

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store