Hello,
I do all my work through x2go (central XFCE desktop server for the company) and I run the nightly Firefox builds.
Certain web pages lead to my entire desktop turning extremely slow, sometimes completely unworkable. This is with only a wireless lan between my terminal and the x2go server.
I understand there's a problem with Firefox here, probably generating too many x events (guess) or similar.
However, it doesn't seem like x2go is working optimally when a single application can spoil the whole desktop like this (even when the windows are on a different workspace or minimized). The solution is simply to close Firefox when the desktop grinds to a halt (a few times per day).
As one of the pages it happened on was our own web page, I looked at the web code to try to track down the problem, and it was bizarrely triggered when many objects on the web page had the background-size property set to 100% in CSS, so there's definitely a Firefox issue involved.
However, I'd like to work out if I can tune x2go to handle this better.
I thought, based on how NX worked, that events were handled locally on the server and only sent across the link when needed. I can't confirm if this is involved, but it certainly seems like something can be improved as windows that are not shown shouldn't, reasonably, be able to interfere.
Does anyone have any input on this? Advice? Should I report a bug?
Many thanks.
Regards, Carl
Am 06.01.2014 19:29, schrieb Carl: [Firefox slowing down X2Go session]
Does anyone have any input on this? Advice? Should I report a bug?
I think it would be interesting to see what happens if you log in via SSH and run "top -i" there. Then, when your session starts to act up, check in your SSH session's top output if Firefox is eating away CPU/RAM and thus bringing the entire server, and not just your particular X2Go-session, to a halt. In that case, it would seem to be unlikely that it is an X2Go issue (though I wouldn't want to rule it out completely). Also, you could try to run an un-accellerated session, with SSH and plain X forwarding through SSH. Note that this will be slower than X2Go from the very beginning, even without Firefox acting up. If you can reproduce the issue with un-accellerated X, it's clearly a Firefox bug, IMHO.
-Stefan
Hi Stefan,
[Firefox slowing down X2Go session]
Does anyone have any input on this? Advice? Should I report a bug?
I think it would be interesting to see what happens if you log in via SSH and run "top -i" there. Then, when your session starts to act up,
If I do that, I can see that Firefox and x2goagent uses about 15%-25% CPU each, but on a rather powerful 2 CPU/4 it's not enough to hog the machine - other users and processes seem to run rather unaffected.
Also, you could try to run an un-accellerated session, with SSH and plain X forwarding through SSH. Note that this will be slower than X2Go from the very beginning, even without Firefox acting up. If you can reproduce the issue with un-accellerated X, it's clearly a Firefox bug, IMHO.
Good test, thanks. I've done this now, and the results are a little confusing. With network speed set to lan and image compression disabled, it is definitely better, although video suffers.
Firefox uses the CPU noticeable still but x2goagent does not.
Firefox slows itself down on these pages, but other applications on my desktop run fine and if I switch to another viewport/desktop, there seems to be no impact from Firefox's troubles.
Given that the issue still appears, I think you are right about it being a Firefox issue. Maybe x2go could handle it smoother, but it's still just a weird scenario so I think I'll report this as a bug to Mozilla only (if I can work out how to use their bug reporting).
Thanks!
Kind Regards, Carl
Am 06.01.2014 20:31, schrieb Carl:
Also, you could try to run an un-accellerated session, with SSH and plain X forwarding through SSH. Note that this will be slower than X2Go from the very beginning, even without Firefox acting up. If you can reproduce the issue with un-accellerated X, it's clearly a Firefox bug, IMHO.
Good test, thanks. I've done this now, and the results are a little confusing. With network speed set to lan and image compression disabled, it is definitely better, although video suffers.
Uh, using x2goclient with "lan/no image compression" isn't the same as running ssh -X and forwarding the display. While your results surely are interesting and increase the suspicion that Firefox is the real culprit here, there's still a faint chance that x2go is doing something it shouldn't do. So just to be sure, run ssh -X, execute Firefox from the shell (again, this will most likely be noticeably slower than through X2Go), and see what happens.
-Stefan
Hi Stefan,
Uh, using x2goclient with "lan/no image compression" isn't the same as running ssh -X and forwarding the display. While your results surely
I see what you mean now..
However, I have now spotted that the issue goes away completely if I set my x2go session to use only 256k jpeg compression.
That also seems to make remote video like youtube usable.
I think, based on that, that running my X session entirely over SSH becomes redundant - it must have something to do with the x2go compression.
Of course, the main cause of the problem is still Firefox, but for the purposes of dealing with misbehaving applications like this, jpeg seems better.
It's possible there's something wrong with the Debian packages though, because many compression methods like Tight, RDP etc simply crash the session immediately before it's shown.
Thanks, Carl
Am 06.01.2014 21:50, schrieb Carl:
It's possible there's something wrong with the Debian packages though, because many compression methods like Tight, RDP etc simply crash the session immediately before it's shown.
Mike, do you have any input on this? I can confirm that I couldn't log in to your X2Go server with compression set to "tight", either. Same issue that Carl is seeing here.
-Stefan
On Mo 06 Jan 2014 22:02:36 CET, Stefan Baur wrote:
Am 06.01.2014 21:50, schrieb Carl:
It's possible there's something wrong with the Debian packages though, because many compression methods like Tight, RDP etc simply crash the session immediately before it's shown.
Mike, do you have any input on this? I can confirm that I couldn't
log in to your X2Go server with compression set to "tight", either.
Same issue that Carl is seeing here.
We possibly lack build dependencies in debian/control of nx-libs. It
would need someone to study the header includes in nxcomp (in
nx-libs.git) to figure that out.
Mike
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
-
Carl -
Mike Gabriel -
Stefan Baur