7.2.572 Mini (maybe) very slow to "start up" [Local vault sync]
Not sure if this started today with 572 or the last few with 570+ but when I enter my MP in mini, the usual first time waking up 1P, it literally takes 15-30 seconds for it to respond and fill in the field I'm waiting for. It's easily 2 or 3 times longer than it was when we were discussing this a few months ago with 7.1.
PC been rebooted many times along the way (like today), SSD, 16 GB RAM....
I can send a report, of course. Any ideas?
1Password Version: 7.2.572
Extension Version: 4.7.2.90
OS Version: Win10 1803
Sync Type: Dropbox
Comments
-
Hi @leesweet,
Thanks for writing in.
Are you seeing this every time you unlock 1Password mini or only after the computer wakes up/unlocked? 15-30 seconds is about the time where 1Password is syncing your 1Password data in the background and that can cause 1Password mini to experience some lag. It's not intended but we don't have a quick fix for this at the moment, it'll require a larger update later.
0 -
No, it's not the PC 'unsleeping' at all. If it's still 1P syncing, then that's fine. Just wanted to be sure it wasn't something else.
0 -
Hi @leesweet,
1Password does starts its sync 10 seconds after every unlock.
To rule this out, open the main 1Password app while locked and go to the
Help Menu > Show 1Password console. Now, unlock 1Password mini, watch the console, does it appear to have network sync/auth activity before 1Password mini starts to work normally?0 -
Very weird. Did what you said, and it worked fine, console had nothing except the showPopup which (mini) worked immediately. Went to another website to test again, and it hung and ended up with 55 sec (55,613 msec) of sync.
INF:3796 │ opw::api:1817 │ 24148ms │ firefox: -> showPopup
INF:3796 │ opw::api:1817 │ 88288ms │ Sync local vault 1 in 55,607ms
folder 1,256 +0 -0 ∆0
database 1,258 +0 -0 ∆1,258
INF:3796 │ opw::api:1817 │ 88290ms │ > sync
account id: 1; type: L
time: 55,613msINF:3796 │ opw::api:1817 │ 88294ms │ firefox: -> showPopup
INF:3796 │ opw::api:1817 │ 127713ms │ firefox: -> showPopup0 -
Hi @leesweet,
That’s weird. Just to be clear, there was no sync before the first mini> showPopup? It was supposed to start 10 seconds in unless there were some delays.
As you notice, it took ~56 seconds to finish the sync before it could do the second mini> showPopup (same process ID INF:
3798). That’s something we’re trying to split into their own thread in a future update.Are you seeing the sync every time you switch tab, though? It should be normal from now on until the next lock.
0 -
That’s the whole console history. I’ll do some more similar testing today. 10 seconds delay is one thing but a minute makes it virtually unusable hence this post.
0 -
indeed. Definitely keep us apprised!
0 -
Did it again, locked PC, unlocked, waited watching console to see it do the sync, same deal, and then of course it worked normally.
So the question is why does it need to sync on every unlock? Can't there be a check to see if there is anything TO sync? (It's already synced today, BTW, before I did this last one.)
INF:17152 │ opw::api:1817 │ 55662667ms │ App locked (windows locked (SessionLock)).
INF:17152 │ opw::api:1817 │ 55675789ms │ Locking app with windows locked (SessionUnlock).
INF:3796 │ opw::api:1817 │ 55702116ms │ firefox: -> showPopup
INF:3796 │ opw::api:1817 │ 55766298ms │ Sync local vault 1 in 54,463ms
folder 1,256 +0 -0 ∆0
database 1,258 +0 -0 ∆1,258
INF:3796 │ opw::api:1817 │ 55766301ms │ > sync
account id: 1; type: L
time: 54,466msINF:3796 │ opw::api:1817 │ 55792080ms │ firefox: -> showPopup
INF:3796 │ opw::api:1817 │ 55793511ms │ firefox: <- collectDocuments. INF:3796 │ opw::api:1817 │ 55793533ms │ firefox: -> collectDocumentResults
INF:3796 │ opw::api:1817 │ 55793582ms │ firefox: <- executeFillScript. INF:3796 │ opw::api:1817 │ 55793618ms │ firefox: -> fillItemResults
INF:3796 │ opw::api:1817 │ 55793887ms │ firefox: -> pressEnterKey0 -
Hi @leesweet,
That is the check to see if there's anything to update, it just happens to take a minute to finish because of the size of your vault, we're working on more efficient methods to scan for updates faster and to skip certain files we don't need to scan. The problem is that we need to do this in a separate process, so that the UI doesn't suffer. For an example; 1Password mini has nothing to do with this process, so it should run on its own but sadly, it is impacted by the sync subsystem because of some other methods can't be separated yet. Even in this time and age, multiple processes/threads are still somewhat difficult to work with for most developers but we're working on it.
Notice the two separate
folderanddatabaselines under the sync local vault call; that's because there are two separate areas where your 1Password data lives. Your external OPVault file that you're syncing with other 1Password apps and the internal database.1Password is scanning all files within OPVault (including attachments) to find any updates. If there is no update, it's done. If there is, it'll start the internal sync process to merge the external OPVault data into the local database. You have ~1300 items spread out in 16 large files that it needs to verify plus attachments. Timestamp isn't enough, especially when you can make changes on multiple computers at the same time. We need a better way to skip files that doesn't need to be scanned like the attachments, they rarely are updated.
0 -
I think my main concern and why I posted in the first place is that this appeared/used to take 10 seconds 'when Mini hung on opening' and now it's a 'make the product useless' 55 seconds. Ten seconds is usable....
0 -
Hi @leesweet,
Right, now we've narrowed it to your local vault sync, the next question is have you changed anything to your vault recently, like add a lot of attachments or moved it to a different location or did nothing change?
We haven't changed anything in this area for the 7.2 version for sure.
We'd like to see the directory content of your local vault; can you email us your 1Password diagnostics report. Please use this guide to generate the report and email it to us at support+windows@1Password.com. Also, in the email, include the link to this thread along with your forum username, so that we can connect the email to this thread.
Let us know here when you've sent it, so we can confirm we got the email.
0 -
No changes at all I can think of, PC runs its usual tons of stuff but load isn't high when 1P is opening. Which is why I thought it was the new software....
Email on its way!
0 -
Got it, will reply as soon as we find something in it.
ref: PJC-47972-895
0 -
Thanks!
0 -
Appreciate that. Still wondering what changed in loading the last few beta releases. I never watched it on the console but the ‘hang time’ was never more than 10 seconds.
Looking forward to whatever fix you can make!
0 -
Nothing changed for sure, we're reviewed the code and it is exactly the same. We think what you're seeing is a threading issue, just more work being done in the background that is slowing down the sync.
0 -
Ah, gotcha, makes sense. Thanks for the insight!
0 -
Thanks, won’t get hopes up then! :)
0 -
Hey, thanks for understanding, and for your continued feedback on the beta! :chuffed:
0 -
This exact same thing is happening with me. I thought I was going crazy, but the moment from selecting the Chrome/FireFox 1Password extension to autofill it takes a solid 15-45 seconds for 1password to respond.
1Password 7.2.576
- Dropbox Sync for 2 of 3 vaults
- Windows client
- 16GB RAM
- SSD for 1Password / OS / Vaults
INF:6952 │ 1Password::api:1790 │ 1549446ms │ > sync
time: 47,757msINF:6952 │ 1Password::api:1790 │ 1550053ms │ chrome: -> showPopup
INF:6952 │ 1Password::api:1790 │ 1550514ms │ chrome: -> showPopup
INF:6952 │ 1Password::api:1790 │ 1612575ms │ chrome: -> showPopup0 -
@hayrun: You've got a super long sync right before that show popup there, so that's definitely the culprit. If you wait for that sync to finish it should be snappier. I know that's a really long time to do nothing, but if you unlock the main 1Password app, wait about 5 minutes, then show mini, do you find things are quicker?
0 -
I don't believe that time is accurate as the sync most definitely doesn't take 5 minutes. It's about 30 seconds and then it responds. It's usually the filling of items initially after unlocked that takes the longest. It eventually catches up but this most definitely was not the behavior in previous versions. iOS with its internal Dropbox sync is instant.
On a somewhat related topic, is there a reason we must rely on the external Dropbox application for syncing rather than 1Password making API calls like what the mobile clients look like?
0 -
I don't believe that time is accurate as the sync most definitely doesn't take 5 minutes. It's about 30 seconds and then it responds. It's usually the filling of items initially after unlocked that takes the longest. It eventually catches up but this most definitely was not the behavior in previous versions. iOS with its internal Dropbox sync is instant.
@hayrun: The time is definitely accurate, at least according to your system timer. Kate isn't suggesting that sync alone takes 5 minutes (though it could, depending on your data and connection). When unlocking, 1Password does a lot of things including sync, and right now they're not prioritized as efficiently as we'd like, so they can each slow down the others. If 1Password was only syncing, it probably wouldn't take that long, but it's almost certainly checking Watchtower, decrypting data, and a lot of other stuff concurrently. We'll be addressing these performance bottlenecks in an update.
On a somewhat related topic, is there a reason we must rely on the external Dropbox application for syncing rather than 1Password making API calls like what the mobile clients look like?
It's not a "must", but it makes sense to use the Dropbox client on the desktop since it's available. We don't have that option on iOS, so there we must use the APIs. That's all well and good (apart from extra development and testing that means time spent not doing other things), but when they change their APIs it means that folks stuck on an older version can no longer sync, even when we've put the time and effort into supporting the new ones — as we did last year. There just isn't an upside to writing sync code where we don't have to.
0 -
Understood. I'm hopeful the fixes are coming soon. Thanks.
0 -
It's basically all we're working on on Windows for now. I can't say for certain when we'll have an update for everyone, but it's at the top of our priority list for 7.3. Thanks for your patience while we make the necessary changes. :)
0 -
I just want to mentioned I also see extreme slowness when I use Ctrl+\ to auto fill in Chrome. I'm using Dropbox sync as well and the issue seems to be related to VPN. When I'm disconnected from VPN, it seems a little faster. The slowness also impacts editing entries in the vault.
Shouldn't all modification be local and sync be done in the background without slowing down the foreground operation? I doubt that's what 1Password is doing at the moment due to the extreme slowness. This is not good, the sync should be lowest priority unless it's on demand, or at least have it done on a sub process without affecting the main one.
0 -
Indeed, while 1Password is syncing and performing other processes in the background on unlock things slow down until all of that is complete. I'm not aware of anything involving 1Password that wouldn't be impacted, which is why this is our focus currently.
0 -
While it's probably not practical to enumerate everything 1Password is doing in the background, since you mentioned VPN I should also note that detection of network settings for proxy will come into play there as well. So it may be slightly different in your case technically, but as a user the solution will be the same: hang tight for the update. :)
0
