Decision on Remote Support Tool- ScreenConnect
-
@jaredbusch said in Decision on Remote Support Tool- ScreenConnect:
@scottalanmiller said in Decision on Remote Support Tool- ScreenConnect:
@jaredbusch said in Decision on Remote Support Tool- ScreenConnect:
But if I had to use it more daily than I do, I would likely accept the higher cost of WIndows for the better performance. The lag and sluggishness or horrible comparatively.
Where do you see the lag? In starting up sessions?
Using it. All the time.
Like once IN a session? I don't see that at all. Once the session is set up (which was never instant - Windows with double the RAM or not) it's surprisingly fast.
Like I said we moved from Windows on Azure to Linux on Digital Ocean with less than half of the assigned resources and did not see it slow down. If we dropped much below half, then it was slow. But at the half point, we saw parity.
Maybe more recent updates have changed this, but half the RAM, just as fast here. Way under half the cost.
-
@jaredbusch said in Decision on Remote Support Tool- ScreenConnect:
@scottalanmiller said in Decision on Remote Support Tool- ScreenConnect:
I suspect that around 6GB of RAM, Windows is faster - because you get past the point where Windows is needing more and Linux keeps adding RAM that it has no way to use.
At the ranges where Linux runs well and scaling up doesn't make much sense, Windows will struggle to run just the OS. I bet if we tested both at different RAM points, you'd find a curve where Linux outperforms dramatically until you get rather high in RAM. Then Windows would take over. But only at immense cost.
Stop speculating and actually try it. It is not even close to comparatively performant.
2 vCPU
4GB RAMWindows 2012 R2 versus CentOS 7
I have done this many times.
But we DID try it. Linux whomped on Windows.
-
Just for reference, and maybe this matters, ours has long been on Fedora. It is Fedora 26 now. Maybe that is a bit faster than CentOS?
-
@scottalanmiller said in Decision on Remote Support Tool- ScreenConnect:
@jaredbusch said in Decision on Remote Support Tool- ScreenConnect:
@scottalanmiller said in Decision on Remote Support Tool- ScreenConnect:
I suspect that around 6GB of RAM, Windows is faster - because you get past the point where Windows is needing more and Linux keeps adding RAM that it has no way to use.
At the ranges where Linux runs well and scaling up doesn't make much sense, Windows will struggle to run just the OS. I bet if we tested both at different RAM points, you'd find a curve where Linux outperforms dramatically until you get rather high in RAM. Then Windows would take over. But only at immense cost.
Stop speculating and actually try it. It is not even close to comparatively performant.
2 vCPU
4GB RAMWindows 2012 R2 versus CentOS 7
I have done this many times.
But we DID try it. Linux whomped on Windows.
No, you moved one time. Between totally different backends.
On the other hand, I setup a test environment on the same hypervisor with two identically configured virtual machines. Installing CentOS 7 on one and Windows Server 2012 R2 on the other. Then I backed up the ScreenConnect system and restored it into each.
-
Just so that you can see why going to 4GB would artificially favour Windows, this is the RAM usage on Fedora. Anything over 1GB of RAM is totally wasted.
$ free -m total used free shared buff/cache available Mem: 1999 473 170 1 1354 1311 -
@scottalanmiller said in Decision on Remote Support Tool- ScreenConnect:
Just so that you can see why going to 4GB would artificially favour Windows, this is the RAM usage on Fedora. Anything over 1GB of RAM is totally wasted.
$ free -m total used free shared buff/cache available Mem: 1999 473 170 1 1354 1311Well that is provably false. Here is CentOS 7
-
@jaredbusch said in Decision on Remote Support Tool- ScreenConnect:
On the other hand, I setup a test environment on the same hypervisor with two identically configured virtual machines. Installing CentOS 7 on one and Windows Server 2012 R2 on the other. Then I backed up the ScreenConnect system and restored it into each.
I get it, but that's a lot of resources. Try it at 1GB between the two, and I'm confident you'll find exactly the opposite. That Linux is dramatically faster. 4GB is a ridiculous amount of RAM for a workload that should be very light.
-
@jaredbusch said in Decision on Remote Support Tool- ScreenConnect:
@scottalanmiller said in Decision on Remote Support Tool- ScreenConnect:
Just so that you can see why going to 4GB would artificially favour Windows, this is the RAM usage on Fedora. Anything over 1GB of RAM is totally wasted.
$ free -m total used free shared buff/cache available Mem: 1999 473 170 1 1354 1311Well that is provably false. Here is CentOS 7
Right, so like I said, it might be a CentOS performance issue rather than a Linux one. I assume that your Mono process is using all that RAM? Ours is using 18%, but it isn't choosing to grow any farther.
-
What are you running on there? I just looked at a few CentOS 7 servers and they aren't using nearly that much, either.
-
@scottalanmiller said in Decision on Remote Support Tool- ScreenConnect:
What are you running on there? I just looked at a few CentOS 7 servers and they aren't using nearly that much, either.
nothing but ScreenConnect. I always single purpose my machines , barring licensing constraints.
-
-
@jaredbusch said in Decision on Remote Support Tool- ScreenConnect:
@scottalanmiller said in Decision on Remote Support Tool- ScreenConnect:
@jaredbusch said in Decision on Remote Support Tool- ScreenConnect:
But if I had to use it more daily than I do, I would likely accept the higher cost of WIndows for the better performance. The lag and sluggishness or horrible comparatively.
Where do you see the lag? In starting up sessions?
Using it. All the time.
Mine are very laggy
-
@dashrender said in Decision on Remote Support Tool- ScreenConnect:
@jaredbusch said in Decision on Remote Support Tool- ScreenConnect:
@scottalanmiller said in Decision on Remote Support Tool- ScreenConnect:
@jaredbusch said in Decision on Remote Support Tool- ScreenConnect:
But if I had to use it more daily than I do, I would likely accept the higher cost of WIndows for the better performance. The lag and sluggishness or horrible comparatively.
Where do you see the lag? In starting up sessions?
Using it. All the time.
Mine are very laggy
Can you define laggy? What operations do you do where you see lag?
-
@scottalanmiller said in Decision on Remote Support Tool- ScreenConnect:
@dashrender said in Decision on Remote Support Tool- ScreenConnect:
@jaredbusch said in Decision on Remote Support Tool- ScreenConnect:
@scottalanmiller said in Decision on Remote Support Tool- ScreenConnect:
@jaredbusch said in Decision on Remote Support Tool- ScreenConnect:
But if I had to use it more daily than I do, I would likely accept the higher cost of WIndows for the better performance. The lag and sluggishness or horrible comparatively.
Where do you see the lag? In starting up sessions?
Using it. All the time.
Mine are very laggy
Can you define laggy? What operations do you do where you see lag?
I click the start button and it take 2 seconds to respond.
-
Text entry is much faster almost no lag but clicking around is very slow.
-
@dashrender said in Decision on Remote Support Tool- ScreenConnect:
Text entry is much faster almost no lag but clicking around is very slow.
Okay, so you mean in the sessions themselves. That's a tough one to pin down, because there is a WAN link involved. Are you comparing against a similar RDP session done remotely? Are you saying that SC is lagging in absolute, or relative terms? All remote access is laggy to some degree.
-
Could the performance difference between the Linux VMs has something to do with the hypervisors?
-
@black3dynamite said in Decision on Remote Support Tool- ScreenConnect:
Could the performance difference between the Linux VMs has something to do with the hypervisors?
Not likely, the only thing that really varies there are the PV drivers.
-
@scottalanmiller said in Decision on Remote Support Tool- ScreenConnect:
@dashrender said in Decision on Remote Support Tool- ScreenConnect:
Text entry is much faster almost no lag but clicking around is very slow.
Okay, so you mean in the sessions themselves. That's a tough one to pin down, because there is a WAN link involved. Are you comparing against a similar RDP session done remotely? Are you saying that SC is lagging in absolute, or relative terms? All remote access is laggy to some degree.
Scott, if you make the comparison test I said, you would not see that session lag on a windows based system. It is as simple as that.
-
@jaredbusch said in Decision on Remote Support Tool- ScreenConnect:
@scottalanmiller said in Decision on Remote Support Tool- ScreenConnect:
@dashrender said in Decision on Remote Support Tool- ScreenConnect:
Text entry is much faster almost no lag but clicking around is very slow.
Okay, so you mean in the sessions themselves. That's a tough one to pin down, because there is a WAN link involved. Are you comparing against a similar RDP session done remotely? Are you saying that SC is lagging in absolute, or relative terms? All remote access is laggy to some degree.
Scott, if you make the comparison test I said, you would not see that session lag on a windows based system. It is as simple as that.
Sure, that would make sense, if I could see the lag on the Linux system. Of course I won't see it on a new, much more powerful Windows system, I don't see it on the current one. I tested just now, and even connecting to a machine on a really slow network connection (at MQ's office) the lag is tiny, nothing like Dash is seeing. So until I can reproduce it on Linux, not seeing it on Windows wouldn't tell me anything.
