skate get {key} takes ~1.17s, skate get {key} takes ~2.9s to execute -- slow crypt check?

[shpigunov]

Hi, I really like the idea behind skate as a tiny key:value store in the command line. However, for a tiny CLI program, skate appears to run a bit too slow.

When I timed the execution on my machine, I got the following:

$ time skate get kitty -> ~1.175s, (one example: 0.08s user 0.05s system 10% cpu 1.179 total);
$ time skate set kitty meow -> ~2.6s, (one example: 0.17s user 0.11s system 10% cpu 2.573 total)

First, I figured that my system/shell setup may be at fault, so I created a clean environment by running docker run -it golang:latest, but the times I got didn't differ all that much:

$ time skate get kitty -> ~1.171s, (one example: 0.049s user 0.029s system 1.179 total);
$ time skate set kitty meow -> ~2.5s, (one example: 0.094s user 0.096s system 2.473 total)

I figured that since the CPU load was low compared to the overall execution time, the execution is IO bound. And sure enough, when I disconnected all network adapters, I got the failed crypt check message.

So my question is: does Skate have to phone home for every (even non-synced) operation to check the crypt keys? And if so, can the requests be made faster using caching on the server side? Or alternatively, can the crypt check be disabled in the options?

[toby]

Hi @shpigunov you're correct in that skate is currently hitting the server to grab the encrypt keys. We definitely want to work on caching them locally, storing them encrypted and decrypting them with your ssh key. You can also try to run charm serve locally or on your network and change the CHARM_HOST env var to point at that machine if you want to see how fast it is without the network jump. We wanted to get this out for feedback, but definitely plan on improving performance. We'll leave this issue open so you can track.

[shpigunov]

Hi @toby thanks for your response. I will try to launch a Charm server locally and measure my times again.

[shpigunov]

Okay, I launched the charm server locally, and the exec times have drastically improved as expected:

$ time skate get kitty -> ~0.09s, (one example: 0.05s user 0.02s system 75% cpu 0.095 total);
$ time skate set kitty meow -> ~0.13s, (one example: 0.08s user 0.05s system 97% cpu 0.133 total)

[coljac]

I've also found that skate is a bit too slow to use remotely:

$ time skate set test hello
skate set test hello  0.05s user 0.06s system 1% cpu 6.693 total

I will use a local charm as suggested, but will follow this issue to see if and when a big speedup eventuates!

[pavdmyt]

It would be nice to have an option to disable network sync altogether and rely only on local files.

[sheldonhull]

I ran into this today as well after reading some other issues, I thought caching was enabled after the first pull, but pulling a set of secrets via my .envrc file cost 16 seconds total to load. This makes it unusable for me to replace local token pulls.

I had some issues running charm locally via docker that aren't relevant to this issue, so I'll give that or the local charm binary at try again when I get a chance.