mirror of
https://github.com/1Remote/1Remote.git
synced 2026-04-25 13:36:03 +03:00
[GH-ISSUE #445] Bad startup performance depending on network availability #2284
Labels
No labels
area-configuration
area-ct-app
area-ct-rdp
area-ct-remoteapp
area-ct-ssh
area-ct-vnc
area-launcher
area-list
area-tags
area-teamwork
bug
chore
dependencies
general-build/ci
general-performance
general-refactor
general-security
general-supportive
general-ux
meta-documentation
meta-enhancement
meta-enhancement
meta-feature
meta-help-wanted
meta-unknown-error
priority-hi
priority-low
pull-request
question
resolution-duplicate
resolution-invalid
resolution-wontfix
stale
task-put-off
task-still-considering
task-working-in-progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/1Remote#2284
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @majkinetor on GitHub (Jul 4, 2023).
Original GitHub issue: https://github.com/1Remote/1Remote/issues/445
Originally assigned to: @VShawn on GitHub.
The first one is just bad (~5s)
details
The second one is extremelly bad, it takes 20 seconds. I disconnected from the VPN but later noticed that Internet wasn't working. It takes 20+s to show up:
details
I noticed btw that there is no timer any more when VPN is disconnected, only Reconnecting constantly shown.
Any connection problem shouldn't influence main window - local database should always work. Even without local database (which is currently not possible), we should see remote database names ASAP.
Logs shows that it tries to connect to Github among other things, probably to check latest version?
details
1Remote.log_20230704.md
@VShawn commented on GitHub (Jul 8, 2023):
Sorry for the delay. I found a stray kitten while walking my dog on a rainy night last week, so my free time has been dedicated to taking care of the cat and dog lately.
The loading screen is waiting for the database to finish loading. Therefore, if the network connection is poor, it can take a significant amount of time. This is especially noticeable when the VPN disconnects, as it will wait until it times out.
So this is not a performance issue. Perhaps you can consider optimizing the loading screen to improve the user experience in such situations.
You may consider ending the loading animation once the local database is loaded, and making remote database to continue loading in the background (it was how PRM implemented in the past). However, please note that after the MySQL database finishes loading, the main view / launcher view must be refreshed. And if the user is browsing data at the moment, they will see the screen refresh, and the selected items will be lost.
fixed by
github.com/1Remote/1Remote@fd92d0f791Yes
@majkinetor commented on GitHub (Jul 9, 2023):
All is excued then :) Life before other things!
Sounds like a bad design choice to me. Why is this different then any other moment of time - I don't have loading screen when network is down while using the app, nor I should have it here. We should IMO have main window imediatelly which should show all databases by default in reconnecting state.
You can fix that, its easy to remember currently selected items. This can also happen any time when the app is running.
Actually, the worst is when internet is down so it looks like Github check is producing the major problem while it should be irrelevant. When internet is up and VPN is down I get maybe 2s delay, while its 20s otherwise.
So, I think we should have it like this:
I think there is nothing we can do to prevent glitches - for example remote database could be the first one listed, so it will inevitably move the local database from view down once it is loaded (and it will load slower then the local one). Alternativelly, we can maybe wait for all databases to load on start, and then all show them at once, which I don't think is a good UI if remote loading is for some reason slow. Note that this would all be irrelevant if you adopted my way of caching data (https://github.com/1Remote/1Remote/discussions/414) in which cases all databases would be local and we would have UI glitches only if remote is substantiatelly changed from the last run, which is something that should almost never happen.
@VShawn commented on GitHub (Jul 9, 2023):
No Github check is totally background and nothing to do with the
loading viewhttps://github.com/1Remote/1Remote/blob/main/Ui/AppInit.cs#L332-L345
The above code snippet is the control code for
loading page. It first shows theloading pageand then create threads to read data from database asynchronously.Once all the threads have finished or if a timeout occurs, it then kill the
loading page. So it's nothing to do withGithub checkI still stand by my previous viewpoint that data from mysql should not be cached in local files.
I will go towards this direction :)
@majkinetor commented on GitHub (Jul 9, 2023):
You are beeing stuborn now for no good reason :)
Gr8, that
WaitAllhas to fly...@VShawn commented on GitHub (Jul 9, 2023):
Let's move the relevant discussion back to #414.
@VShawn commented on GitHub (Jul 10, 2023):
test with an offline mysql db
https://github.com/1Remote/1Remote/assets/10143738/ac5b76b8-9f44-4f08-aaec-46ff8492847b
@majkinetor commented on GitHub (Jul 10, 2023):
Gr8. I will check out tomorrow.
@majkinetor commented on GitHub (Jul 11, 2023):
I confirm it works good now.
Pause is cute, certainly one way to solve the selection problem :)