[Docs] YCSB requires number of rows in usertable to be equal to recordcount parameter for successful run

[mrajcevic01]

Description

Running the YCSB benchmark using our documentation I ran into an issue where there were many [READ-FAILED] and [UPDATE-FAILED] results during my testing. After further investigation this was due to the LOAD phase of the YCSB run:

./bin/ycsb load yugabyteSQL -s \
      -P db.properties           \
      -P workloads/workloada     \
      -p recordcount=1000000     \
      -p operationcount=10000000 \
      -p threadcount=32          \
      -p maxexecutiontime=180

Due to the maxexecutiontime parameter above the run times out after 180 seconds. In this particular case the LOAD timed out prior to inserting all 1000000 rows called out by recordcount above. Due to this when we run one of the workloads:

./bin/ycsb run yugabyteSQL -s  \
      -P db.properties           \
      -P workloads/workloada     \
      -p recordcount=1000000     \
      -p operationcount=10000000 \
      -p threadcount=256         \
      -p maxexecutiontime=180

We see these [READ-FAILED] and [UPDATE-FAILED] results due to X rows being inserted during the load phase and the workload looking for the recordcount value of 1000000 rows.

• Users can fix this by setting the recordcount parameter to a value of X. Meaning if your table has 700k rows after the load phase you should set recordcount to 700000.

We can help users avoid this by:

1. Removing the maxexecutiontime parameter from the examples in the documentation
2. Calling out a disclaimer that users need to check that number of table rows is equal to the recordcount.

I prefer the first option since it requires no work for the user.

FYI this is not seen when running the benchmark using the run_ysql.sh script as called out in our documentation because it calls the load without the maxexecutiontime parameter. However this does not work on YB Managed, for example, without modifications.