New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The Multiplexing is very slow #1872
Comments
Can you describe in more detail what you're doing when you notice that it is slow? Have you tried adjusting the |
I notice it is slow because when I type, it response not instantly, as I describe in the original post I even can see the double line under the characters I type in in short time. for example below, if I type in "ls example" I will see the double under line from "l" to "e" in order for short time. and if I try to delete the "ls example" the cursor even can reach 'h".
The network is a bit slow I know, ping round-trip time is 226ms. I use local_echo_threshold_ms = 10 and it doesn't help. |
the terminal is not large, I use small terminal. 1920x1280 and font size is 14 |
try to use ssh domain instead of tls domain, the result is same. |
to be more clear, the client is windows and the server is Linux, I cannot try to use local wezterm to connect mux server, since my server doesn't have GUI support. |
Try setting |
looks not helping |
updated the tile to remove TLS since I found it is not TLS specific, the problem happens whatever the multiplexing is by TLS or UNIX domain |
I actually have had a similar issue. When using the mux unix domain, and navigating while holding down arrows or hjkl in neovim, the repeat actually gets stuck and I cannot even stop it without spamming opposite keys which then have their own delayed repeat until the cursor finally stops. I have since stopped using the unix domain mux just because there is a huge delay sometitmes, while a direct I can say that this seems to happen after a little while into the server running after it has used up some memory. Killing and restarting the process earns me some more responsiveness for a little while but in the end becomes enough of an issue to have left the feature altogether. I will work on getting some data,logs,rec of the issue but I had been keeping an eye on this issue because of it mentioning slowness, and now that OP mentions it happening over even unix domain for them too I figured I should chime in as me too. |
This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further. |
Used sometime to dig it, the slow looks from proxy more than network transmission somehow. |
From the above log, you can see between the typing "x" and "i", there is a big pause happen from 22:55:13.619 to 22:55:13.869 This happened when I just type "exit" in terminal the fd list lrwx------ 1 joe joe 64 Dec 7 23:09 0 -> /dev/pts/2 |
Hi @wez, I can provide more specific log if you need. The functionality is really good and useful, I hate I cannot use RUST to program. But I can make some change and build to test, if you have any idea. |
I have just met what looks like the same problem when using a unix socket to connect to a remote host. The slowdown I am experiencing seems related to redrawing operations. Some observations:
One difference between the two editors is that This is with Edit: Just tested with an SSH domain and observed the same behavior. Without multiplexing (i.e., just SSH'ing into the server) does not lead to any slowdown even for maximized terminals. |
I experienced the same with both direct ssh and multiplexing. Using ssh from wsl works normally as already reported. |
I can also confirm this, and agreeing with cunha that vim is especially slow when multiplexing (using wezterm connect to a GCP VM). The lag is still noticeable with Smaller windows help (e.g. using several horizontal splits). If there's anything I can do to help profile the issue, let me know. |
At 80x24 (< 2k cells), sending all 24 lines of the viewport as an optimistic prefetch is "OK", but for full screen 4k (80*250 = 20k cells) the volume is oversized and pushes latency up. This commit dials that back down to the minimal useful data; the cursor row + any changed rows in the viewport. When navigating in vim that reduces things down to 2 rows of prefetch per movement, assuming that the status line is being updated to show the cursor position. This feels a little more snappy for me. refs: #2503 refs: #1872
Since d36ad7c was merged I wanted to check again on latest master. I can't connect to the mux server anymore though. @wez did you change something there since last release that I'm not aware of? The standard config I used before does not connect to a local unix socket anymore, but works on latest release: config.unix_domains = {
{
name = 'unix',
},
}
config.default_gui_startup_args = { 'connect', 'unix' }
|
@cd-a share the error message(s) that you see? |
@wez I'd love to, but there are none :) When I run this config on the release, and there is no socket open yet, on first terminal it briefly shows no socket yet, and creates it, then every terminal afterwards connects to it. So when I close, reopen, it loads the layout again. On latest master, nothing. No message about missing socket, no attaching to socket. Just behaves as if there is no mux set up. I tried killing the existing socket from the release version, that maybe master would do it differently, but no. Any way I can log this verbosely? |
@cd-a please file an issue with complete repro steps and config |
So after wez helped me figure out how to properly start the mux server on the master build, here are my findings using:
It's blazingly fast now, I can hardly notice a difference to non-mux performance now. Maybe a tiny fraction, but only noticeable if I compare them directly against each other... or maybe I'm even hallucinating that one. It just works great! So I will now switch to the mux version, loving it. Great work wez! |
Can you specify any config and minimum wezterm build dates that are required to get fast mux on a 4k full screen? I'm running |
@joshuarubin d36ad7c or later |
thanks for the info. is that for both the client and server, or is it ok for one side to be older? |
While that change in theory only changed some logic on the server, there were some other multiplexer changes that bumped the CODEC_VERSION over the weekend, and the client will give up talking to a server with a mismatching CODEC VERSION. So you'll want to upgrade both the client and the server. |
This should be resolved now in It typically takes about an hour before commits are available as nightly builds for all platforms. Linux builds are the fastest to build and are often available within about 20 minutes. Windows and macOS builds take a bit longer. Please take a few moments to try out the fix and let me know how that works out. You can find the nightly downloads for your system in the wezterm installation docs. If you prefer to use packages provided by your distribution or package manager of choice and don't want to replace that with a nightly download, keep in mind that you can download portable packages (eg: a If you are eager and can build from source then you may be able to try this out more quickly. |
@joshuarubin for the config, please check #3438 where it's linked with the description. |
Thanks for your help. I think I've got it working. New issue, I can make separately, but in case you are already aware, on main when I'm connected to an ssh domain and do
This is on MacOS and my home dir is in /Users, so I'm not sure why that's happening. |
@joshuarubin please file a separate issue so that this one can remain focused on the performance aspect |
I've tried the latest commit and the sluggish behavior hasn't disappeared for me. I don't know if it's faster than before, but it's still significantly slower than a normal SSH session. Scrolling in neovim, for example, is very slow. |
My tests indicate UNIX domains are no longer impacted by the severe slowdown I observed before. Vim on gigantic terminal window now updates as fast as expected for a remote (SSH) session. 💯 I used
and the following UNIX domain config:
|
I've tried with an identical I don't understand what I'm doing differently. |
I can confirm the experience is quite smooth with the nightly build. My setup: OS: Windows 10 unix_domains = {
{
name = 'wsl-mux',
serve_command = { 'wsl', 'wezterm-mux-server', '--daemonize' },
},
}, WSL: Ubuntu 20.04 (with nightly I logon to WSL and just ssh and work on remote servers all day, working great! |
For me the performance has increased a lot too, so much that I can now use it as a daily driver! 🎉 Still feel it's a little bit slower than iTerm2 + ssh + Tmux, but it's good enough for me. |
@calops if you have vim plugins that cause every line to change when moving the cursor up or down (eg: displaying relative line numbers at the start of each line), then wezterm will still need to send a lot of data on each cursor movement. Perhaps there is something like that in your config that is triggering the worst case performance? |
@wez Yes, I do have something like this, but that's irrelevant for a simple use-case like "scrolling through a file" where lines are gonna get redrawn no matter what. And even simple stuff such as selecting text (which shouldn't redraw much) has a noticeable latency, which is made very obvious when doing it with the mouse. The real problem here is that a plain So it seems obvious to me that wezterm adds a significant overhead to this. Is this a technical limitation for this solution, or is there hope that it could be improved somehow? |
Yes, there is more overhead because there obviously is more going on. One of my hopes is that enough users are willing to lend support that I can afford to |
@wez I am still seeing this performance bottle neck as well with MacOS <> Linux and the latest nightly. I am more than happy to help dive into the code, but would need some assistance as to where to start. If you can give me some guidance as to where to start, I can take a whack at what is going on as I have a simple reproduction setup and can dive in over the next few weeks as I should have some spare time. Let me know if that makes sense to you! |
@supernomad thanks for the offer, but I think it will likely be more time consuming to bootstrap someone than for me to sit down and do the work. At a high level the issue is this:
So the change granularity is The end state I have in mind is:
That would bring the data to be processed down closer to These are pretty significant changes across several layers; it's not a small task. |
I did some additional tests on a 136x566 window and indeed could see some slowdown with This is over the Internet when connected to a server that is 30ms away; one's mileage will likely vary depending on connection quality. |
That part wasn't obvious to me, actually. What specifically is done in addition to what an SSH/tmux stack is doing? |
@calops you can read the code if you're really interested. It's too much to explain here for a casual comment; it will take time I don't have and it will have only cost and no benefit to me to do so to someone that isn't committed to spending some of their time also working on this, and I don't believe that you are that person. |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
What Operating System(s) are you seeing this problem on?
Windows
WezTerm version
20220101-133340
Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?
No, and I'll explain why below
Describe the bug
The functionality of TLS multiplexing is very good but a bit slow, if I directly use ssh connect to the host, every thing is fine but if I use the TLS multiplexing, it is very slow, I even can see a double line under the character I typed in. If I use delete the cursor even can go back beyond my prompt to the first column of the terminal. Since it it is connecting to company's server, I cannot capture what it is, sorry about that.
To Reproduce
configure a tls multiplexing server and connect to it.
Configuration
no specific
Expected Behavior
run at least as fast as ssh connection
Logs
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: