design client performance test rigs

[VJag]

**Is your feature request related to a problem? Please describe. Design the tests that measure the performance bottlenecks which will become driving factors to refactor/redesign the client

**Describe the solution you'd like By identifying and measuring performance bottlenecks and how and what clogs the event loop we should be able to design the system for the parallelism

Describe alternatives you've considered NA

Additional context NA

[gkc]

High priority because we have a platform objective of having reliable latency for notification delivery.

Note: We do not have a formal objective at this time. We need to agree a set of SLOs along the following lines

• Notification delivery latency from one atSign secondary to another should be less than 50-milliseconds-plus-speed-of-light for 99.9% of notifications after initial secondary-to-secondary connection has been established.
  • Also need SLO for time to complete full pol handshake, to establish new secondary-to-secondary connection
  • And an agreement as to how long a secondary-to-secondary connection's allowable idle time should be
• Notification delivery latency from secondary to connected client should be less than 50-milliseconds-plus-speed-of-light for 99.9% of notifications after initial client catch-up has completed

[purnimavenkatasubbu]

The performance tests include

• [x] Notification text latency

What are we measuring: These tests measure the latency/time difference between the time that the notification is sent from the sender's client to the time the notification is received by the client of the recipient.

Scenarios - Sender notifies using notify:text and receiver is receiving notifications (without sync) - The objective of this scenario is to measure the performance overhead of sync on the notification being notified to the client. - Sender notifies using notify:text and receiver is receiving notification and also updating the key at the same time (with sync). The objective of this scenario is to measure the performance overhead of sync on the notification being notified to the client.

• [x] Sync latency

What are we measuring These tests measure the latency/time difference between the time that the key is "updatedAt" from the sender's client to the time the key is "updatedAt" by the client of the recipient.

In client_sdk, the following parameters control the sync behavior

• syncRequestThreshold - The number of requests needed for a sync to be triggered.
• syncRequestTriggerInSeconds - The number of seconds after which a sync should be triggered
• syncRunIntervalSeconds - The interval after which the sync runs.

Scenarios

•   Sync latency with default threshold values i.e., 
        syncRequestThreshold = 3,
        syncRequestTriggerInSeconds = 3,
        syncRunIntervalSeconds = 5
  

•    Sync latency with 
          syncRequestThreshold = 1,
          syncRequestTriggerInSeconds = 3,
          syncRunIntervalSeconds = 3
  

•    Sync latency with 
          syncRequestThreshold = 2,
          syncRequestTriggerInSeconds = 3,
          syncRunIntervalSeconds = 3
  

•    Sync latency with 
          syncRequestThreshold = 1,
          syncRequestTriggerInSeconds = 3,
          syncRunIntervalSeconds = 2
  

•     Sync latency with 
          syncRequestThreshold = 1,
          syncRequestTriggerInSeconds = 2,
          syncRunIntervalSeconds = 1
  

•        Sync latency with 
          syncRequestThreshold = 1,
          syncRequestTriggerInSeconds = 2,
          syncRunIntervalSeconds = 2
  

• [ ] Design isolates to better study the parallelism required in at_client

For tests and observation results. Please go to the following comment

[purnimavenkatasubbu]

The design isolates part is pending in the ticket. That can be tracked as part of the ticket Build ticket