Getting started with 1Password for your growing team, or refining your setup? Our Secured Success quickstart guide is for you.
Forum Discussion
ddribin
2 years 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 https://github.com/sharkdp/hyperfine 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
13 Replies
- maver1ckNew Contributor
Hi 1P_SimonH
Any chance to get any reasonable response from 1password team ?
There are multiple threads on this topic and I didn't see any suggestions from your team how to fix this problem.- 1P_SimonH
Community Manager
- maver1ckNew Contributor
Hi 1P_SimonH ,
I checked different techniques mentioned in this and other threads and generally speaking they're not doing big difference.
Changing from names to IDs has marginal effect as everything sit in cache.
The problem is that debug mode doesn't show proper timestamps (or maybe I don't know how to enable them) so it's difficult to say what operation is bottleneck.
But from output observation I would say problem lays in first two NM requests.time op read op://vault/OPENAI_API_KEY/password --debug 5:24PM | DEBUG | Session delegation enabled 5:24PM | DEBUG | NM request: NmRequestAccounts 5:24PM | DEBUG | NM response: Success 5:24PM | DEBUG | NM request: NmRequestAccounts 5:24PM | DEBUG | NM response: Success 5:24PM | DEBUG | InitDefaultCache: successfully initialized cache 5:24PM | DEBUG | EncryptedKeysets: Cache hit on keyset 5:24PM | DEBUG | AllVaults: cache hit on vault j2.....................sa 5:24PM | DEBUG | AllVaults: cache hit on vault bg........................ty 5:24PM | DEBUG | AllVaults: cache hit on vaultk7.................ny 5:24PM | DEBUG | VaultItems: cache hit on vault items of vault k7.................ny 5:24PM | DEBUG | VaultItems: cache hit on vault items of vault k7.................ny 5:24PM | DEBUG | Item: VaultItems cache hit for vault k7.................ny - validating staleness using item version 5:24PM | DEBUG | Item: cache hit on item xe...................c474 of vault k7.................ny op read op://vault/OPENAI_API_KEY/password --debug 0.05s user 0.03s system 6% cpu 1.274 total
- pinzhangNew Contributor
Very reasonable request, I'm encountering the same slow issue as well.
- jhogendornNew 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.
- 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. - 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.
- 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
- jhogendornNew 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
- jhogendornNew 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.
- 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
- 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 https://ansible.readthedocs.io/en/latest/ to setup a new server. I figured I'd put all the secrets, such as the
sudo
password, in 1Password and then use the https://docs.ansible.com/ansible/latest/collections/community/general/onepassword_lookup.html 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 https://docs.ansible.com/ansible/latest/vault_guide/index.html, 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 https://restic.readthedocs.io/en/stable/ to backup some Linux servers to https://www.backblaze.com/cloud-storage. 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.