Replay performance

The number of requests that are issued by IBM Cloud® Object Storage Replay is throttled to ensure that overall dsNet performance remains at the agreed level.

You can control throttling by the number of settings in a configuration file. All settings are optional. The following screen shows an example of the default values.

"replay": {
     "max_requests_per_second": 1000,
     "max_parallel_list": 10,
     "parallel_head_per_list": 15,
     "list_objects_size": 1000
}

Process count

The following list shows an example of how 161 processes are divided. Figure 1 shows a caution message of how the number of processes should not exceed 161.

  • One main process
  • 10 List worker processes
  • 150 HEAD worker processes
Figure 1. Python process count
Python process count

Maximum Replay performance

Replay and Notifier maximize performance on a 64 core Intel(R) Xeon(R) CPU E5-2690 v3 @ 2.60GHz server is 2300 objects that are scanned and notified per second with a dsNet with 6 accessers and 12 slicestors under customer load at 50 percent capacity.

"replay": {
     "max_requests_per_second": 2300,
     "max_parallel_list": 10,
     "parallel_head_per_list": 15,
     "list_objects_size": 1000
 }

The recommendation is to start the replay at a rate of 1000 objects scanned per second. Measure the latency degradation of customer traffic and increase the scanning rate until the maximum acceptable degradation is reached.

One thousand objects per second on the net, which is a 5 - 27 percent increase of write operations, the latency (larger increase for smaller size files) and around 10 percent for read operations latency were measured.

At 2000 objects a second, a 10 - 50 percent increase of write operations latency and in the range 18 - 28 percent, and 10 percent for read operations latency were measured.