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's avatar
ddribin
New Contributor
9 months ago

"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's avatar
    AndyW1P
    Icon for 1Password Team rank1Password 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
  • ddribin's avatar
    ddribin
    New 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 the community.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 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 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 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.

  • ddribin's avatar
    ddribin
    New 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

  • jhogendorn's avatar
    jhogendorn
    Occasional 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.

  • jhogendorn's avatar
    jhogendorn
    Occasional 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

  • reps's avatar
    reps
    New 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

  • 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.

  • robxyz's avatar
    robxyz
    New 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.