// wrong_shard_server sometimes comes from the only nonfailed server, so we need to avoid a fast spin
doubleWRONG_SHARD_SERVER_DELAY;// SOMEDAY: This delay can limit performance of retrieving data when the cache is mostly wrong (e.g. dumping the database after a test)
doubleFUTURE_VERSION_RETRY_DELAY;
intREPLY_BYTE_LIMIT;
doubleDEFAULT_BACKOFF;
doubleDEFAULT_MAX_BACKOFF;
doubleBACKOFF_GROWTH_RATE;
int64_tTRANSACTION_SIZE_LIMIT;
int64_tKEY_SIZE_LIMIT;
int64_tSYSTEM_KEY_SIZE_LIMIT;
int64_tVALUE_SIZE_LIMIT;
int64_tSPLIT_KEY_SIZE_LIMIT;
intMAX_BATCH_SIZE;
doubleGRV_BATCH_TIMEOUT;
// When locationCache in DatabaseContext gets to be this size, items will be evicted
intLOCATION_CACHE_EVICTION_SIZE;
intLOCATION_CACHE_EVICTION_SIZE_SIM;
intGET_RANGE_SHARD_LIMIT;
intWARM_RANGE_SHARD_LIMIT;
intSTORAGE_METRICS_SHARD_LIMIT;
doubleSTORAGE_METRICS_UNFAIR_SPLIT_LIMIT;
doubleSTORAGE_METRICS_TOO_MANY_SHARDS_DELAY;
//KeyRangeMap
intKRM_GET_RANGE_LIMIT;
intKRM_GET_RANGE_LIMIT_BYTES;//This must be sufficiently larger than KEY_SIZE_LIMIT to ensure that at least two entries will be returned from an attempt to read a key range map
intDEFAULT_MAX_OUTSTANDING_WATCHES;
intABSOLUTE_MAX_WATCHES;//The client cannot set the max outstanding watches higher than this
doubleWATCH_POLLING_TIME;
doubleIS_ACCEPTABLE_DELAY;
// Core
intCORE_VERSIONSPERSECOND;// This is defined within the server but used for knobs based on server value