What is the default value for --max-parallel-submissions and what is its exact meaning?

There’s a command line parameter for sandbox-classes called --max-parallel-submissions. The command help doesn’t specify any default. What is this set to? And what exactly does the parallelism here refer to? Is it the threshold before the process signals backpressure? What’s the implication of increasing this, does the process just use more memory?

That’s the maximum number of commands waiting to be sequenced after being evaluated by the engine. The default value is 512. This is a global limit, meant to not have an unbounded buffer of transaction evaluated correctly but getting sequenced.

That is one of the three back-pressure gates in the sandbox, the other two acting on a per party basis: the first is commands waiting to be submitted (the default is 512 and it’s currently not configurable) and --max-commands-in-flight (submitted commands waiting to be completed, whose default is currently 256).

I understand it’s not as good as interactive help (please do open a ticket if you want us to track this), but you can also check out here for reference.

digital-asset/daml/blob/655c0a54254a1fa163da3102cdf6ddee8638d0c7/ledger/sandbox/src/main/scala/com/digitalasset/platform/configuration/CommandConfiguration.scala#L8-L47

/**
  * Reaching either [[inputBufferSize]] or [[maxCommandsInFlight]] will trigger
  * back-pressure by [[com.daml.ledger.client.services.commands.CommandClient]].
  *
  * Reaching [[maxParallelSubmissions]] will trigger back-pressure
  * by [[com.daml.platform.sandbox.stores.ledger.sql.SqlLedger]].
  *
  * @param inputBufferSize
  *        Maximum number of commands waiting to be submitted for each party.
  * @param maxParallelSubmissions
  *        Maximum number of commands waiting to be sequenced after being evaluated by the engine.
  *        This does _not_ apply to on-X ledgers, where sequencing happens after the evaluated
  *        transaction has been shipped via the WriteService.
  * @param maxCommandsInFlight
  *        Maximum number of submitted commands waiting to be completed for each party.
  * @param limitMaxCommandsInFlight
  *        Whether [[maxCommandsInFlight]] should be honored or not.
  * @param retentionPeriod
  *        For how long the command service will keep an active command tracker for a given party.
  *        A longer retention period allows to not instantiate a new tracker for a party that seldom acts.

Thanks, do you know if there are metrics to monitor these respective queue sizes? I’d like to know which back-pressure gate I’m hitting (getting a RESOURCE_EXHAUSTED response).

I don’t think we have them instrumented yet, no.

This PR does not add reporting on the hit threshold but adds the possibility of configuring the input buffer size and hopefully makes the help text a bit better.