nosqlbench / nosqlbench

The open source, pluggable, nosql benchmarking suite.

NoSQLBench 5

The Open Source, Pluggable, NoSQL Benchmarking Suite

👉 The current version of NoSQLBench in development is 5.21, which is based on Java 21 LTS. All new language features in Java 21, and some preview features may be used. There are significant improvements in this branch which will be documented before a main release is published. If you are presently using NoSQLBench for testing, and are not actively developing against the code base, it is recommended that you stay on the latest 5.17 release until an official 5.21 release is available. What's in store for 5.21.

Get it Here

Contribute to NoSQLBench

Read the Docs

What is NoSQLBench?

NoSQLBench is a serious performance testing tool for the NoSQL ecosystem. It brings together features and capabilities that are not found in any other tool.

• You can run common testing workloads directly from the command line. You can start doing this within 5 minutes of reading this.
• You can generate virtual data sets of arbitrary size, with deterministic data and statistically shaped values.
• You can design custom workloads that emulate your application, contained in a single file, based on statement templates - no IDE or coding required.
• When needed, you can open the access panels and rewire the runtime behavior of NoSQLBench to do advanced testing, including a full scripting environment with Javascript.

The core machinery of NoSQLBench has been built with attention to detail. It has been battle tested within DataStax and in the NoSQL ecosystem as a way to help users validate their data models, baseline system performance, and qualify system designs for scale.

In short, NoSQLBench wishes to be a programmable power tool for performance testing. However, it is somewhat generic. The core runtime of NoSQLBench doesn't know directly about a particular type of system, or protocol. It simply provides a suitable machine harness in which to put your drivers and testing logic. If you know how to build a client for a particular kind of system, it will let you load it like a plugin and control it dynamically. However, several protocols are supported out of the box as bundled drivers.

Origins

The code in this project comes from multiple sources. The procedural data generation capability was known before as 'Virtual Data Set' OSS project. The core runtime and scripting harness was from the 'EngineBlock' OSS project. The CQL driver module was previously used within DataStax. In March of 2020, DataStax and the project maintainers for these projects decided to put everything into one OSS project in order to make contributions and sharing easier for everyone. Thus, the new project name and structure was launched as nosqlbench.io. NoSQLBench is an independent project that is sponsored by DataStax.

We offer NoSQLBench as a new way of thinking about testing systems. It is not limited to testing only one type of system. It is our wish to build a community of users and practice around this project so that everyone in the NoSQL ecosystem can benefit from common concepts and understanding and reliable patterns of use.

Getting Support

In general, our goals with NoSQLBench are to make the help systems and examples wrap around the users like a suit of armor, so that they feel capable of doing most things autonomously. Please keep this in mind when looking for personal support form our community, and help us find those places where the docs are lacking. Maybe you can help us by adding some missing docs!

NoSQLBench Discord Server

We have a discord server. This is where users and developers can discuss anything about NoSQLBench and support each other. Please join us there if you are a new user of NoSQLBench!

Contributing

We are actively looking for contributors to help make NoSQLBench better. This is an ambitious project that is just finding its stride. If you want to be part of the next chapter in NoSQLBench development please look at CONTRIBUTING for ideas, and jump in where you feel comfortable.

All contributors are expected to abide by the CODE_OF_CONDUCT.

License

All of the code in this repository is licensed under the APL version 2. If you contribute to this project, then you must agree to license all of your contributions under this license.

System Compatibility

This is a Linux targeted tool, as most cloud/nosql testing is done on Linux instances. Some support for other systems is available, but more work is needed to support them fully. Here is what is supported for each:

1. on Linux, all features are supported, for both nb5.jar as well as the appimage binary nb
2. on Mac, all features are supported, with nb5.jar.
3. on Windows, all features are supported, with nb5.jar.

Thanks

	This project is sponsored by DataStax -- The Open, Multi-Cloud Stack for Modern Data Apps built on Apache Cassandra™, Kubernetes *Based*, Developer *Ready* & Cloud *Delivered* and designed from the ground up to run anywhere, on any cloud, in any datacenter, and in every possible combination. DataStax delivers the ultimate hybrid and multi-cloud database.
	This project uses tools provided by YourKit, LLC. YourKit supports open source projects with its full-featured Java Profiler. YourKit, LLC is the creator of YourKit Java Profiler and YourKit .NET Profiler, innovative and intelligent tools for profiling Java and .NET applications.

Contributors

Checkout all our wonderful contributors here.

---

nosqlbench's Issues

Give the user a warning if no statements are found for an activity

If a user is running an activity with tag filters which select zero statements, a warning should be issued. It should not be flagged as an error, due to some integration requirements with other testing harnesses.

Originally filed as engineblock/engineblock#167

Provided uniform sub-parameter conventions and API

Some arguments to the main CLI and activity parameters are used to install an optional component, which has its own initialization properties. An example of this is the set of metrics reporting options which follow a
--log-histograms 'histodata.log:.*specialmetrics:10s'
pattern where you can specify either logfile, logfile:filter or logfile:filter:interval.

The ability to pass a set of initialization parameters by name is needed across optional components so that the pattern remains familiar and self-explanatory to users. All "sub parameter' semantics should be converted to use this new API. Design: TBD

originally filed as engineblock/engineblock#142

Provide safety checks against local resource saturation

The local CPU, memory, network, and IO resource utilization should be provided as native metrics to be reported alongside all other metrics streams.

As well, when these resources are over a given moving-average threshold, a warning should be reported to the user in relaxed mode, and an error should be thrown in strict mode.

The threshold should also be customizable.

originally reported as engineblock/engineblock#78

Add search function for docs

Guidebook - Add support for TLS (https)

The guidebook doesn't have TLS support yet. This should be added without adding dependencies on external libraries if possible.

CpuInfo class is too Linux dependent

Right now, CpuInfo and CpuInfo.ProcDetails classes are too Linux dependent as they are reading /proc/cpuinfo, and other files from /proc/ that aren't available on the Mac OS, and other platforms... We need to decrease dependency on the low level stuff like this, by maybe using https://github.com/oshi/oshi, or something like...

Scenario wraps user exceptions in runtime exceptions

We should keep the exception type to clean up logging downstream.

https://github.com/engineblock/engineblock/blob/master/eb-core/src/main/java/io/engineblock/core/ActivityExecutor.java#L97

originally filed as engineblock/engineblock#193 by @phact

bug - parameter injection into scripts is malformed

Shown by the default empty parameter set:

// Rendered Script
// params:
params=
};

Provide a way to `start and reset` activity def for scripting

Generic statement operator API

A basic statement operator API has been introduced in the CQL activity type which should be generalized and hoisted into nosqlbench core. This feature should be considered experimental and subject to change until the API is finalized in core. The rest of this ticket explains the current feature and next steps.

The optional statement param rsoperators can have a comma separated list of operators to apply to any result set produced from a CQL operation.

Supported rsoperators include:

• pushvars - Push the current thread-local vars map onto a new one, duplicating the values
• popvars - Pop the thread-local vars map, revealing the one before the last push, or throw an error if there was only one on the stack
• clearvars - Clear the current thread-local vars map
• trace - Modify a statement to be traced, and then log the trace into a file
• log - Log the toString version of a statement to the standard log output
• assert_singlerow - throw a ResultSetVerificationException unless the result set contains exactly one row
• print - Print the toString representation of a statement to System.out

The optional statement param rowoperators can have a comma separated list of operators to apply to each row in any result set that a CQL operation produces.

Supported rowoperators include:

• saverows - Add the row to a thread-local rows list
• savevars - Save the named fields from the current row to the thread-local vars map
• saveglobalvars - Save the named fields from the current row to the global vars map
• print - print the toString representation of the current row to System.out

Next Steps

The API for this feature should be made consistent in the nosqlbench core so that it works across all activity types in a simple and re-usable way. However, the result type of an operation varies across activity types, so a mechanism that allows for type variance is necessary. Alternately, the embedded scripting may be used as a more general purpose facility for decorating operations and side-effects that occur before or after operations.

Add current docs for bundling ActivityTypes and file resources

originally filed as engineblock/engineblock#33

add support for editorconfig

https://editorconfig.org/ is a way to specify editor settings, such as, ident width, etc. for multiple editors. It would be useful to add support for it.

Multi-Client load generation

Managing a load bank is a basic feature of a scale-out testing system.

It is advised to use scaling math and a few client nodes at most for most practical scenarios. Other testing harnesses which utilize nosqlbench already can provide the ability to coordinate multiple client nodes across a set of logically divided operations. In those cases, a self-hosted multi-client coordinator is not needed.

However, to support richer integration and scale-out capability for nosqlbench, a scenario orchestrator is needed. This is essentially an inter-node eventing system which can wrap all of the scenario life-cycle events into a messaging layer that is responsible for setup, timing, and delegation of logically separated details across node instances.

detailed design: TBD

originally filed as engineblock/engineblock#5

activity parameters should not care about upper/lower case

originally filed as engineblock/engineblock#159

Add metrics API docs for developers

Add docs to support the use of the metrics library, including local enhancements such as

• ServiceLoader style registry mapping
• HDR and resetting histograms
• default units, like nanoseconds
• Guides on how and where to initialize metrics instances in drivers
• How to find metrics names suitable for scripting, and what they mean

originally filed as engineblock/engineblock#62

Warn the user if the CPU scheduler is not set to performance

originally filed as engineblock/engineblock#146

Parameter validation should be uniform throughout

Presently, when a user uses a parameter which is not recognized by an activity (or activity type), no warning is provided. This creates confusion for users when they expect that the behavior they are seeing is directly related to setting that parameter.

A basic parameter metadata API should be provided that each activity or component can use to identify supported parameters and their meanings. This should model fluent option parser APIs, but it should be tailored to the semantics of nosqlbench components.

All parameters should be "consumed" during initialization. Any remaining parameters that are left over should cause a warning in relaxed mode and an error in strict mode.

A user should be able to ask the parameter metadata for what parameters are supported using basic command line help options.

Parameter metadata should be added to any related topics that are seeded with markdown help files when appropriate.

originally filed as engineblock/engineblock#133

CLI - allow global options to appear within activity params

Sometimes, users will insert a global option within a list of activity params.

Considering the basic CLI example, nb run type=cql yaml=... host=..., if a user adds a global option in between, like nb run type=cql --report-csv-to metrics yaml=... host=..., then an error will be thrown.

The second form should be supported, since forcing the user to re-configure their command is higher friction and doesn't significantly add to clarity.

Static guidebook via docs discovery

We now have a static guidebook on the way (Thanks @phact!).

The next phase of improvement on this should be to eliminate local scripting needed to find and assemble the content for the static view. Specifically, if we can delegate the markdown content discovery to a docsfinder command or something similar, we should.

The end goal is for an activity type contributor to be able to add docs in java using the extant mechanisms, and have that appear both the dynamic and the static guidebook forms without further integration or scripting work.

Require activity type docs

Every activity type should be required to have some documentation in order for the activity type to be recognized by the loader. An error message should be thrown by the loader indicating to the developer what to do in order to fix the issue, including the specific file name that is needed.

Related to #24

originally filed as engineblock/engineblock#2

Promote the recycles parameter to the Input API

For basic inputs (not cycle logs, etc), the parameter recycles will cause the input cycle range to be re-used some number of times. This defaults to 0.

The recycles parameter needs to be made standard across the input implementations.

originally logged as engineblock/engineblock#152

two boxes shown on matching diagnostic when multiple predicates are applied to tags

Tag filtering with complex tag expressions shows two checks when only one tag set is matched ultimately.

originally logged as engineblock/engineblock#179

Redesign core eventing and messaging APIs

The core runtime needs to have a more generic eventing interface. A basic event-reactor design is sufficient. This is to address a couple of shortcomings in the core architecture:

1. It is difficult to react to external events.
2. Timing and ordering semantics are "best effort" currently with respect to threads and activity controls.
3. Diagnostics for events like starting threads are not easy for novice developers.

A better eventing system will provide a primitive/opaque event queue and explicitly managed event scopes and forwarding between basic components like the scenario, individual activities, and registered event listeners within scenario scripts.

detailed design: TBD

originally filed as engineblock/engineblock#12

CLI - allow --option=value forms (including an equal sign)

The --options format should also support --option=value form instead of just the --option value form, as many users get confused about the difference in the global option form and the activity parameter forms which already support param=value.

The previous support for those options which already support --option value should remain so that the change doesn't break existing tests.

provide an option for `assertive` mode

Assertive mode is a feedback setting which will tell novice users when something doesn't look right for a user-interactive scenario.

Examples:

There are zero cycles in an activity
There are zero activites in a scenario
a parameter isn't being used
In some cases, especially with automated testing calling into eb, it is valid for these conditions to occur. For those cases, it would be nice to be able to say assertive=false to delegate trust to the caller for configuration sanity.

Originally filed as engineblock/engineblock#184

Automate builds and maven deployment via github actions

Updates to a release branch should automatically trigger builds and deployment to maven central.

Add annotated developer docs for the async API

originally filed as engineblock/engineblock#154

Version number should be added to logs and possibly error messages

When diagnosing an issue, it is sometimes difficult to verify whether an issue should have been fixed or not if the diagnostic output doesn't indicate the version. It would be much easier if all diagnostic logs had an version included, like this:

"diagnostic error line here .... (version 3.12.43)"

originally filed as engineblock/engineblock#149

The --list-metrics option needs to be updated or removed

This option doesn't appear to work, and hasn't been used much.
It should be updated or removed. At the very least, an integration test needs to be added for it.

originally filed as engineblock/engineblock#129

Make scenerio scripting IDE-friendly

The intellisense and other IDE helpers that make fluent API usage so easy for developers can be extended to scenario scripting. This means that any <<name:value>> template parameters should instead use the TEMPLATE(name,value) form, and that all similar token based support should do something similar. The point is to make these calls follow standard "C-like" syntax that will not confuse an IDEs syntax parsing and intellisense logic.

originally filed as engineblock/engineblock#63

Reconsider parameter names for yaml and type

When using a built in workload, yaml is rather meaningless and when using a custom yaml it is still rather vague. Aaron proposes we use the parameter workload instead. We could also use activity-definition if we wanted to match the language in the source code but I think workload is more intuitive for a new user.

type is a bit harder because nosqlbench supports things like stdout, tcpclient, kafka, etc. that do not fit into a more specific description like database or driver. We could use the term activity or activity-type to match what we call things in the source code but again, not sure how intuitive those are for new users. Open to suggestions on a better term for type.

Regardless, we would continue to support the old parameter names for backwards compatibility.

Filter static markdown the same as dynamic markdown

Rework specification of the dependency versions

Right now, only some of the components are declared in the dependencyManagement and buildManagement section of mvn-defaults project, while versions are explicitly specified in the multiple pom files, so this may lead to problems in the future when changing dependencies.

it would be useful to consolidate all dependencies in the dependencyManagement & buildManagement sections of mvn-defaults, and don't specify versions explicitly in the pom files, except mvn-defaults.

consolidate MetricsCloseable and IShutdown interfaces

originally filed as engineblock/engineblock#130

Progress meter improvements (start, end, ETA)

The progress indicator should include details on the start cycle, end cycle, and estimate time remaining.

2 different classes use same case-insensitive name...

On Mac OS I'm getting following warning when cloning repository:

warning: the following paths have collided (e.g. case-sensitive paths
on a case-insensitive filesystem) and only one from the same
colliding group is in the working tree:
  'activitytype-cql/src/main/java/io/nosqlbench/activitytype/cql/errorhandling/exceptions/CQLCycleException.java'
  'activitytype-cql/src/main/java/io/nosqlbench/activitytype/cql/errorhandling/exceptions/CqlCycleException.java'

and as result it isn't compilable...

research impacts of TSC on rate limiter

The rate limiter and timer implementations may need to be aware of whether
tsc is enabled, and fall back to a more robust strategy if not.

Reference: http://btorpey.github.io/blog/2014/02/18/clock-sources-in-linux/

originally filed as engineblock/engineblock#147

Allow resource extraction with ls, cp, cd commands

With the binary releases, it isn't as obvious how to see what resources are bundled and how to get them out. Some basic commands should be supported which allow for listing and copying out out files.

Provide a Statement configuration API for scripting

he YAML represents a set of data that is a template for statements which can then be used to create executable operations. Sometimes, users need to configure statements that are generated from templates at a higher-level than YAML. For example, a user may need to create many variations of a statement which might appear in an application without having to enumerate them all, precisely by using the same type of data-dependent logic that a client application may use.

It should be possible to provide an object directly from the scripting layer to modify the statement template configuration. This would be an API, and may take the form of a scripting extension which is built on top of the standard statement configuration API.

detailed design: TBD

originally filed as engineblock/engineblock#67

Custom timer metrics

Some tests currently use the stride as an implicit bracketing around a group of statements for metrics, but the tests in question, this is complicated by the need to measure multiple brackets of statements.

If a statement parameter were added which can start and stop named metric timers, users could define the boundaries of metrics as they need. A proposed config format for this follows.

Phase 1:
This allows named metrics timers to be added with the existing APIs without requiring the more complete operators API, which will eventually subsume this functionality.

start-local-timer

A statement parameter like this:

statements:
 - s1: a statement here
   param:
      start-local-timer: timer-named-foo

should start a named timer under the name provided, available in a thread-local cache, before the statement executes.

stop-local-timer

A statement parameter like this:

statements:
 - s2: another statement here
   param:
     stop-local-timer: timer-named-foo

should stop a named timer under the name provided, available in a thread-local cache, after the statement completes. If such named timer is not present, then an exception should be thrown.

For the initial phase of this implementation, it is ok to implement this per-activity type. The next phase should pull this up into the nosqlbench core APIs via a uniform mechanism.

make all scenario-level CLI options indirect through the scripting API

When managing advanced scenarios via scripting, it is problematic to also have to rely on a specific command-line setup. It should be possible to access the services which are configured or initialized via command line options through the scripting environment as well.

detailed design: TBD

originally filed as engineblock/engineblock#81

Support StmtDef aware operators in activity types

Allow StmtDef injection into runtime elements which can use them.

To support certain downstream requirements such as statement injection, it is necessary to implement the ability for some operators to introspect the statement configuration and related run-time data structures. To allow for this, an auxiliary set of interfaces will be provided to allow these operators to declare awareness of these configuration elements.

Either the activity type interface should allow for statements to be provided via a single-method decorator interface, or an information API should be provided as standard to all activity type instances.

originally logged as engineblock/engineblock#175

cql help doesn't mention truststore & tspass options

right now, cql help describes only keystore & kspass options, but not truststore & tspass that are required when using SSL

Under extreme contention, rate limiter slows down

In big metal testing, a condition was found in which a workload could run at 280K ops per second with no rate limiter, but when rate limited to around 180K, only a fraction of this was achievable. The overhead in this was all client side, as confirmed by testing both cases alternately. The main culprit is probably the fact that the client was running on a very large system with a very large threadpool of 1K threads.

Suggested lines of study:

Reproduce extreme thread contention on lower core boxes and document behavior.
Move the token filler logic into the path of a caller. In high contention scenarios, it may not be reasonable to expect the token filler thread to keep up, even with a higher thread priority.
Ensure that the token filler is doing time deltas from actual fill time, not logically stepping each time. If the latter, the filler could simply bet getting backlogged.
Add some internal metrics to measure when this could happen.
Make it clear for users where the trade-offs are in rate limiter logic. There is no free rate limiting. It may be best to optimize the rate limiter for high contention too, and make all workloads rate limited by some high default, so at least there is a gradual slope between the modes. Setting a workload to not use a rate limiter would be considered a special case, but should be supported.

Originally filed as engineblock/engineblock#170

binding names should allow dashes and similar non-word characters

originally filed as engineblock/engineblock#139

Null binding definitions should issue a warning

Originally logged as engineblock/engineblock#181

12:37:15.681 [scenarios:001] ERROR io.engineblock.script.Scenario - Non-Script error while running scenario:Error initializing activity 'sensors': null
java.lang.RuntimeException: Error initializing activity 'sensors': null
at io.engineblock.core.ActivityExecutor.startActivity(ActivityExecutor.java:98)
at io.engineblock.core.ScenarioController.run(ScenarioController.java:83)
at io.engineblock.core.ScenarioController.run(ScenarioController.java:89)
at io.engineblock.core.ScenarioController.run(ScenarioController.java:96)
at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$1$^eval_/0x00000008401b8c40.:program(:2)
at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:655)
at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:513)
at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:527)
at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:456)
at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine$3.eval(NashornScriptEngine.java:517)
at java.scripting/javax.script.CompiledScript.eval(CompiledScript.java:103)
at io.engineblock.script.Scenario.run(Scenario.java:138)
at io.engineblock.script.Scenario.call(Scenario.java:171)
at io.engineblock.script.Scenario.call(Scenario.java:44)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.NullPointerException: null
at java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1770)
at java.base/java.util.regex.Matcher.reset(Matcher.java:416)
at java.base/java.util.regex.Matcher.(Matcher.java:253)
at java.base/java.util.regex.Pattern.matcher(Pattern.java:1133)
at io.virtdata.core.CompatibilityFixups.fix(CompatibilityFixups.java:64)
at io.virtdata.core.CompatibilityFixups.fixup(CompatibilityFixups.java:53)
at io.virtdata.core.VirtData.getOptionalMapper(VirtData.java:82)
at io.virtdata.core.BindingsTemplate.resolveBindings(BindingsTemplate.java:103)
at io.virtdata.templates.StringBindingsTemplate.resolve(StringBindingsTemplate.java:34)
at io.engineblock.activitytypes.stdout.StdoutActivity.initOpSequencer(StdoutActivity.java:145)
at io.engineblock.activitytypes.stdout.StdoutActivity.initActivity(StdoutActivity.java:99)
at io.engineblock.core.ActivityExecutor.startActivity(ActivityExecutor.java:94)
... 17 common frames omitted

Make ActivityType implementations follow a conformal API

Some conventions of ActivityType design have become evident enough in practice to now hoist some patters into the framework level. This will have multiple benefits:

• Standardize on the conceptual and mechanical patterns needed to implement a well-defined ActivityType.
• Make the contract between the engine and the activity types more explicit.
• Allow for higher reuse and generally higher quality of the core components that ActivityType implementations may depend on.

Originally filed as engineblock/engineblock#86

Scenario nesting should enable orchestration and supervision

Scenarios should be allowed to configure and launch scenarios that they are supervisory to.
This requires some scope nesting capability, but it is needed for any meta orchestration which can be used to handle framework-level errors or events in a robust way.

originally filed as engineblock/engineblock#76

Use typed exceptions for explicit exception handling

There are a few different kinds of errors that can manifest. Depending on where the error is caught, it is usually easy to tell whether or not the error is caused by an internal failure of some kind, or an external configuration issue.

When it is known that the error is caused by a mis-configuration, or something that the user is in control of, then an exception should be thrown of type 'UserException'. This isn't meant to convey that the user is necessarily at fault, but more that the user is in control of the circumstances that created the error, and thus should be informed of the specific issue in a simple and terse way.

A UserException must specify in its message a simple and direct explanation of the problem, including any values specified and any specific reasons that the given values would not work. A UserException should provide ideas to the user on what to try differently, or what type of value or setting would be required to avoid the error.

Handling of exception types must be done in one place, in an exception handler that sees all exceptions that may be thrown to main(). Try/catch block do not directly specify how UserExceptions and other specific types of exceptions will be handled except to enrich (catch and rethrow) an exception as it passes to the main exception handler.

The exception types like UserException should be defined in the core library. Any use of utility functions or other libraries may not have access to the exception types. This is intentional. In such cases where an upstream API module may need to pass an error that may ultimately manifest in a UserException being thrown, it is up to the consuming library to deal with the semantics of correctness and determine when it is appropriate to throw a UserException or something else.

This was originally reported as engineblock/engineblock#194

expose JVM options in the wrapper script when building appimage binary

We will need to be able to specify GC related parameters and heap settings.