Should functions be this slow?

[RRethy]

I'm trying out the wordpress example and running a simple set-namespace function imperatively is taking a long time to run (12seconds). Is this expected or does my setup have something off?

kpt pkg get https://github.com/GoogleContainerTools/kpt.git/package-examples/wordpress@v0.9
KPT_FN_RUNTIME=podman kpt fn eval wordpress --image gcr.io/kpt-fn/set-namespace:v0.1 -- namespace=mywordpress

[RUNNING] "gcr.io/kpt-fn/set-namespace:v0.1"
[PASS] "gcr.io/kpt-fn/set-namespace:v0.1" in 12.1s
  Stderr:
    "WARNING: image platform (linux/amd64) does not match the expected platform (linux/arm64)"

I don't know why "WARNING: image platform (linux/amd64) does not match the expected platform (linux/arm64)" is showing up or how to fix it, that might be slowing things down.

[RRethy]

For version info, I'm building off latest with go install -v github.com/GoogleContainerTools/kpt@main

kpt version

unknown

[droot]

This time runs of a function is expected to run slow because it involves downloading the function image locally subsequent runs should be faster. Can you share the timing numbers for subsequent runs ?

[RRethy]

That was the run after I tried it a few times so the image was present locally. I benchmarked it with hyperfine and it came out to ~10sec:

KPT_FN_RUNTIME=podman hyperfine "kpt fn eval wordpress --image gcr.io/kpt-fn/set-namespace:v0.1 -- namespace=mywordpress"

Benchmark 1: kpt fn eval wordpress --image gcr.io/kpt-fn/set-namespace:v0.1 -- namespace=mywordpress
  Time (mean ± σ):      9.900 s ±  0.137 s    [User: 1.594 s, System: 0.526 s]
  Range (min … max):    9.732 s … 10.149 s    10 runs

And I checked to ensure I have the image locally:

podman images gcr.io/kpt-fn/set-namespace:v0.1

REPOSITORY                   TAG         IMAGE ID      CREATED      SIZE
gcr.io/kpt-fn/set-namespace  v0.1        458467c5662e  2 years ago  17.5 MB

[johnbelamaric]

Yeah, that's not normal :(

[RRethy]

So the issue was the image only had linux/amd64 platform. Using a more recent set-namespace image fixed the issue and improved performance a bit.

$ KPT_FN_RUNTIME=podman kpt fn eval wordpress --image gcr.io/kpt-fn/set-namespace:unstable -- namespace=mywordpress

[RUNNING] "gcr.io/kpt-fn/set-namespace:unstable"
[PASS] "gcr.io/kpt-fn/set-namespace:unstable" in 5.7s
  Results:
    [warning]: Resource(apiVersion=kpt.dev/v1, kind=Kptfile, namespace=mywordpress, name=wordpress) does not have upstream origin.
    [warning]: Resource(apiVersion=kpt.dev/v1, kind=Kptfile, namespace=mywordpress, name=mysql) does not have upstream origin.
    [info]: all matching namespaces are already "mywordpress". no value changed
    [info]: all `depends-on` annotations are up-to-date. no `namespace` changed

$  KPT_FN_RUNTIME=podman kpt fn eval wordpress --image gcr.io/kpt-fn/set-namespace:unstable -- namespace=mywordpress

[RUNNING] "gcr.io/kpt-fn/set-namespace:unstable"
[PASS] "gcr.io/kpt-fn/set-namespace:unstable" in 2.8s
  Results:
    [warning]: Resource(apiVersion=kpt.dev/v1, kind=Kptfile, namespace=mywordpress, name=wordpress) does not have upstream origin.
    [warning]: Resource(apiVersion=kpt.dev/v1, kind=Kptfile, namespace=mywordpress, name=mysql) does not have upstream origin.
    [info]: all matching namespaces are already "mywordpress". no value changed
    [info]: all `depends-on` annotations are up-to-date. no `namespace` changed

I'm now seeing ~3s to run set-namespace (using hyperfine for benchmarking after ensuring the image has been downloaded).

Is that the expected performance? I would have expected something as simple as set-namespace on a couple of resources to take a trivial amount of time. If that's expected, the issue can be closed.

[RRethy]

Going to assume based on testing and mentions in other issues this performance is expected.

[droot]

Thanks @RRethy for the update on the numbers. I have seen little better numbers with docker runtime, not so sure about podman though, but seems to be in expected range.