Signing back into the Community for the first time? You'll need to reset your password to access your account. Find out more.
Forum Discussion
ddribin
9 months agoNew Contributor
"op read" is pretty slow, ~700ms per invocation
Hi all,
I've noticed that op read
is pretty slow, taking on the order of 700ms per invocation. Here's a benchmark using the hyerfine
tool:
% hyperfine --warmup 3 "op read op://private/op-test/password"
Benchmark 1: op read op://private/op-test/password
Time (mean ± σ): 717.2 ms ± 46.6 ms [User: 118.7 ms, System: 39.6 ms]
Range (min … max): 640.8 ms … 782.3 ms 10 runs
Reading a non-password field is about the same:
% hyperfine --warmup 3 "op read op://private/op-test/username"
Benchmark 1: op read op://private/op-test/username
Time (mean ± σ): 733.2 ms ± 52.1 ms [User: 124.0 ms, System: 41.4 ms]
Range (min … max): 680.8 ms … 815.0 ms 10 runs
And using --cache
does not seem to change anything:
% hyperfine --warmup 3 "op --cache read op://private/op-test/password"
Benchmark 1: op --cache read op://private/op-test/password
Time (mean ± σ): 718.8 ms ± 50.3 ms [User: 119.6 ms, System: 39.6 ms]
Range (min … max): 653.7 ms … 806.7 ms 10 runs
This is on a 16-inch MacBook Pro with an M3 Max on Sonoma 14.4.1. I've installed op
via Homebrew.
I'm not sure what the expectation is, but this seems much slower than I expected.
1Password Version: 8.10.30
Extension Version: Not Provided
OS Version: macOS 14.4.1
Browser: Not Provided
- AndyW1P
1Password Team
Hi ddribin!
I appreciate your feedback! I tested this myself and came up with similar results, I tried using UUIDs instead of the vault and item names in the secret reference, and was able to marginally improve the performance. Out of curiosity, were you expecting a faster response time? If so, what are some specific reasons why you were expecting that over what you encountered?
- Andy
- ddribinNew Contributor
Hi AndyW1P! Thank you for the reply!
It's not so much that I was expecting faster times, but I didn't expect it to be so slow. Two places where I've used
op
recently that highlight the issue:First, I've been playing around with Ansible to setup a new server. I figured I'd put all the secrets, such as the
sudo
password, in 1Password and then use thecommunity.general.onepassword
lookup to set playbook variables.It turns out this lookup is extremely slow. It can slow down running playbooks by ~10x! A very simple playbook takes ~13s with the
onepassword
lookup. Switching it out to Ansible Vault, Ansible's own secret manager, the same playbook runs in ~1s.The
onepassword
lookup usesop
under the hood. Apparently it runs it at least once for each task, due partially to Ansible’s lazy variable evaluation, so it adds up quickly.Second, I use Restic to backup some Linux servers to Backblaze B2. Again, I wanted to put all the secrets into 1Password, so I wrote this wrapper script:
```
!/bin/sh
shellcheck disable=SC2155
RESTIC_BUCKET="$(op read "op://$OP_ITEM/bucket")"
RESTIC_PATH="$(op read "op://$OP_ITEM/path")"
export RESTIC_REPOSITORY="b2:$RESTIC_BUCKET:/$RESTIC_PATH"
export RESTIC_PASSWORD="$(op read "op://$OP_ITEM/password")"export B2_ACCOUNT_ID="$(op read "op://$OP_ITEM/keyId")"
export B2_ACCOUNT_KEY="$(op read "op://$OP_ITEM/applicationKey")"exec "$@"
```Now I can run
restic-wrapper restic snapshots
and it all "just works". But, again, I noticed this running very slowly. It takes 4 to 5 seconds just to get to theexec
line, because there are five invocations ofop
.But, yes, both of these cases where unexpected slow, ultimately due to
op
taking ~700ms per invocation. - ddribinNew Contributor
One other odd thing is that running this on an Intel CPU is a fair bit faster. On my 2017 iMac Pro, also running Sonoma 14.4.1, I get a benchmark of ~465ms:
% hyperfine --warmup 3 "op read op://private/op-test/password"
Benchmark 1: op read op://private/op-test/password
Time (mean ± σ): 463.9 ms ± 13.0 ms [User: 126.3 ms, System: 52.9 ms]
Range (min … max): 441.7 ms … 485.8 ms 10 runs
This is a good 235ms faster than the 700ms on my 2023 MacBook Pro with an M3 Max, which is very surprising. I thought maybe it was running through emulation, but it's a native ARM binary:
% file =op
/opt/homebrew/bin/op: Mach-O 64-bit executable arm64
- jhogendornOccasional Contributor
I also find the op read function to be excruciatingly slow, averaging 2.5-3s per invocation. Its so slow it I would assume that it is doing multiple round trips to the internet vault to resolve. the cache flag makes no difference. I'm actually physically faster hitting cmd+shift+space, typing a search, cmd+shift+c, cmd+v, which is honestly kind of nuts. This cmd should be reading from a local vault if available and bound purely by I/O speed. for my use case i've been considering using the security cmd to cache credentials into the macos keychain, which is a silly workaround.
- jhogendornOccasional Contributor
hyperfine --warmup 3 "op read 'op://private/test/password'"
Benchmark 1: op read 'op://private/test/password'
Time (mean ± σ): 2.695 s ± 0.051 s [User: 0.051 s, System: 0.032 s]
Range (min … max): 2.618 s … 2.775 s 10 runs
- repsNew Contributor
shell
hyperfine --warmup 3 'op run -- echo'
Benchmark 1: op run -- echo
Time (mean ± σ): 2.131 s ± 0.066 s [User: 0.063 s, System: 0.020 s]
Range (min … max): 2.012 s … 2.208 s 10 runs
op run is also very slow
- thecurseofrngNew Contributor
Just to add further feedback on the subject, op read takes about 1s here.
shell
❯ hyperfine "op read op://vault/test/credential"
Benchmark 1: op read op://vault/test/credential
Time (mean ± σ): 961.6 ms ± 27.6 ms [User: 101.2 ms, System: 44.4 ms]
Range (min … max): 919.1 ms … 1007.0 ms 10 runs
On top of the Ansible use-case described earlier, this is also an issue for direnv variables, used to populate the shell env automatically on directory traversal. It kind of works with 1-2 secrets, but gets more and more obnoxious once you use more than that.
- robxyzNew Contributor
I ran into this issue as well only after trying to run ansible playbooks against groups or hosts. Seemed a bit slow but worked without error on 1 or 2 hosts but 5 or more I was getting intermittent errors and extremely slow playbook runs. Errors were intermittent as well showing one of two 'ansible.errors.AnsibleLookupError' logs:
Unable to sign in to 1Password. Missing required parameters: username, master_password, subdomain, secret_key.
or
connecting to desktop app: connecting to desktop app timed out, make sure it is installed, running and CLI integration is enabled
When I increased the forks to 10 or 20 from the default 5 in ansible (the amount of parallel sessions it runs) the error popped up immediately and not a single host would gather facts.I'm leaving all these details as I think it is related to this issue as the more hosts / frequent the
op
requests are it seems the slower / more likely to block from the desktop app side.It does make
op
unusable though for ansible and any kind of long playbook or against large groups of hosts unless using the op connect methods which don't resolve the inventory lookups on each task but aren't convenient at all to integrate into exists ansible scripts / roles. - jhogendornOccasional Contributor
I did a more indepth investigation a while back and posted results in this thread FYI.
https://1password.community/discussion/148194/speed-concerns
It seems though that we have zero visibility from anyone at 1p unfortunately.