YurtHub Performance Test

    OpenYurt Version

    Master and WorkNode use the ECSs with different configurations, and the used cluster contains one master and other one hundred worknodes. All worknodes join the cluster by using the command on edge mode.

    Operating System

    CPU

    Memory

    Disk

    Through Promethus collecting three types of indicators from the edge side in the OpenYurt cluster.

    • Resource Occupation：YurtHub container CPU/Mem usage
    • Data Traffic：YurtHub forward the traffic of request
    • Request Delay：the delay of YurtHub forwarding request

    The overall test architecture is shown in the following figure

    Traffic

    • In normal situation, traffic data have a wave of 5min period, and peak ranges 15-20 KB/s
    • In the process of workload deploying, traffic booms one time, and peak is 350 KB/s
    • In the process of workload downloading, traffic alse booms one time, having shorter duration time and higher peak about 780 KB/s

    For further exploration of the source of traffic, we select one machine to analyze the traffic usage YurtHub Performance Test - 图3 The above figure shows the usage of traffic as workload deploying, we can get the rank of usage orderly when traffic mutating:

    • endpointslices, watch, 240 KB/s
    • endpoints, watch, 50 KB/s
    • services, watch, 25 KB/s
    • nodes, watch, 24 KB/s
    • pod, watch, 3 KB/s

    The peak of traffic of machine is approximately 320 KB/s, and those traffic contain mostly watch requests about service. The count of endpoint in service(per service 50 endpoints) may cause such situation. In normal case, the watch request about nodes also causes the variety of traffic of 5min period.

    The above figure show the performance of traffic of machine in the process of uninstalling, total peak of traffic reach about 780k. Sorting by resource and action, the usage of traffic as the following data show:

    • service, watch, 140 KB/s
    • endpoints, watch, 100 KB/s

    When collecting latency, we conclude two types latency:

    • Full_latency：record the total time from request reaching YurtHub to request leaving YurtHub

    • Apiserver_latency：record the time from request forwarded by YurtHub to apiserver

      In the procedure of actual testing, two types latency have no difference, so we have full_latency as standard

    • Delete

    YurtHub Performance Test - 图5

    • Create

    • List

    YurtHub Performance Test - 图7

    • Update

    • Patch

    YurtHub Performance Test - 图9

    • Get

    We can see the most time-spending requests mainly are the request of create/get/list about node and the request of list about service.

    Memory

    YurtHub Performance Test - 图12 The occupation of single core CPU is similar to the usage of traffic, normally periodic wave sustains a low level(approximately 0.02%), two peaks of wave show at times of workload deploying（22%）and workload deleting（25%）.

    • Without the pressure of workload, YurtHub occupys memory of approximately 30-40MB and rare CPU（< 0.02）.
      • CPU mainly apply to handle the request received by YurtHub, and the peak of single core occupation could reach about 25% when resource creating.
      • The level of memory is related to the distribution of workload, and varies about 5MB when resource is created and deleted. After all workloads are deleted, memory occupation of YurtHub reduces largely then back to previous level, and specific causes waits to be analysed.
    • The delay in the procedure of YurtHub forwarding request can be ignored comparing to request itself, and the delay of request mainly is related to the size of request resource.