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

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 uses op 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 the exec line, because there are five invocations of op.

But, yes, both of these cases where unexpected slow, ultimately due to op taking ~700ms per invocation.

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


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.


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


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

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.

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.

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.

Very reasonable request, I'm encountering the same slow issue as well.