Tuning `CommandConfiguration` settings?

Is there any way to change command configuration settings via a config file or command-line parameter?

Specifically, I’m referring to:

digital-asset/daml/blob/a79377cb2d6eb488314c9468d8653b621fcb1d09/ledger/sandbox/src/main/scala/com/digitalasset/platform/configuration/CommandConfiguration.scala

// Copyright (c) 2020 Digital Asset (Switzerland) GmbH and/or its affiliates. All rights reserved.
// SPDX-License-Identifier: Apache-2.0

package com.daml.platform.configuration

import scala.concurrent.duration.{DurationInt, FiniteDuration}

final case class CommandConfiguration(
    inputBufferSize: Int,
    maxParallelSubmissions: Int,
    maxCommandsInFlight: Int,
    limitMaxCommandsInFlight: Boolean,
    retentionPeriod: FiniteDuration
)

object CommandConfiguration {
  lazy val default: CommandConfiguration =
    CommandConfiguration(
      inputBufferSize = 512,
      maxParallelSubmissions = 512,

In particular, we found inputBufferSize to be too low for us during a recent data migration, as we ultimately triggered this error here: daml/HandleOfferResult.scala at a79377cb2d6eb488314c9468d8653b621fcb1d09 · digital-asset/daml · GitHub

We are separately exploring ways to make the migration less intensive on the API, but having an option to tune these values would also help a lot.

inputBufferSize cannot be configured right now but you can just retry the command (after letting some time pass). It probably doesn’t make a lot of sense to increase the queue size if the system cannot handle the pressure.

In case of burst loads in can make sense to configure the system to gracefully handle such peaks. Generally, I’d argue there should be some (even if convoluted) way to configure any setting, the alternative of hardcoding and baking it into the binary is not optimal.

Of course, I agree that it should be tunable. What I’m suggesting is that for a migration, which is a planned event, handling backpressure is a more sustainable solution than increasing the queue size, which could also lead to unpredictable performance fluctuations and increased latency, possibly up to the point where commands start timing out due to a long stay in the queue.

We can override it in our codebase due to our sandbox’s legacy as a much deeper fork than it is today…we found cranking that up to 51,200 from 512 didn’t lead to any adverse performance effects (other than everything working). I don’t disagree that handling backpressure is a thing we can do, but I also suspect that limits like this are artificially throttling the parallelism that sandbox is capable of in some cases.

I was mostly referring to latency-sensitive scenarios. A migrations sounds more like a batch job that doesn’t care too much about that.

EDIT

I realize that in my previous message I completely misspoken, apologies for that.