Latency components of a VM listed in serve.csv as result of TestBenchServe

[niravnshah]

Hi,

I am trying to get the latency components of VM execution by use of TestBenchServe. I am using following command line to get it.

sudo env "PATH=$PATH" go test -v -run TestBenchServe -args -iter 3 -benchDirTest ~/vhive/logs -metricsTest -funcName image_rotate -snapshotsTest 1>~/vhive/logs/vhive.out 2>/dev/null

It works fine, and gives this as output in serve.csv

I see that the Total column is total of all the components - AddInstance,ConnectFuncClient,FcResume,FetchState,FuncInvocation,InstallWS,LoadVMM,ServeUnique.

As i understand, the call hierarchy is like this..

Serve <----------------------------------------------- measured as serveMetric
    AddInstance <------------------------------------- measured as AddInstance
        LoadInstance
            LoadSnapshot 
                FetchState
                LoadSnapshot -| Combination of LoadSnapshot and 
                Activate -----| Activate measured as LoadVMM
                    pollUserPageFaults
                        servePageFaults
                            installWorkingSetPages <-- measured as InstallWS
                            installRegion <----------- measured as ServeUnique
            getFuncClient <--------------------------- measured as ConnectFuncClient
        StartVM is ignored for this discussion
    fwdRPC <------------------------------------------ measured as FuncInvocation

As per this, LoadVMM time should already include time for InstallWS and ServeUnique. And similarly, AddInstance should already include time for LoadVMM and ConnectFuncClient, isn't it?

If so, is there any particular reason why all the times are added as part of Total time? Shouldn't the Total be just the total of AddInstance and FuncInvocation?

I feel I am missing something, as i can clearly see in the pic above that LoadVMM is much less than total of InstallWS and ServeUnique. Why is it so?

[niravnshah]

As per this, LoadVMM time should already include time for InstallWS and ServeUnique.

Ok, i understand for LoadVMM. pollUserPageFaults is started on separate thread, which collects InstallWS and ServeUnique.

However, i see AddInstance() calling LoadInstance() and getFuncClient() sequencially. So, why those components (LoadVMM and ConnectFuncClient) are added again to the total along with AddInstance component?

[ustiugov]

@niravnshah from what I recall, we do not account for AddInstance total delay but break it down using the measurements you mentioned. All in all, we have the following latency components: LoadVMM, connection establishing, and the actual processing.

[ustiugov]

you can refer to the script called run_all.sh in the branch corresponding to the ASPLOS'21 artifact evaluation:
https://github.com/vhive-serverless/vHive/pull/74/files

[niravnshah]

Hi @ustiugov, thanks for the reply.

As mentioned, i get following components by running TestBenchServe

• AddInstance
• FetchState
• LoadVMM
• InstallWS
• ServeUnique
• ConnectFuncClient
• FuncInvocation

From the charts in the ASPLOS 21 paper, can you please confirm which of the above component correspond to the following? Or else, how to obtain these? It is not very clear in the run_all.sh or other scripts about these.

• Function Start-up (in Figure 7)
• Connection restoration (in Figure 8)
• Function Processing (in Figure 8)

Also, it would be nice if you can provide a brief explanation on what each of the following component would mean in the context of a cluster. A more precise explanation about starting and ending point for these time components would be helpful.

• ConnectFuncClient
• FuncInvocation

Thanks in advance,
Nirav.

[ustiugov]

@niravnshah

Function Start-up (in Figure 7): everything before response but after VMM is loaded
Connection restoration (in Figure 8): = ConnectFuncClient
Function Processing (in Figure 8) = FuncInvocation

in that paper, we didn't have a knative cluster. all latencies are local latencies. ConnectFuncClient is between a local agent ("vHive") and the server inside the VM.

[niravnshah]

Thanks for the clarification, @ustiugov. 👍