Remote Desktop
-
I'm not sure which category I should put this in, so I'll start here. We're running an application server with Win2003 on it. RDesktop 6.0 is installed on the application server, but the clients differ. Some of the clients are running XP (RDesktop 5.1-6.0) but the majority of our machines are running win2000, which only support RDesktop 5.1. The problem is that the application we run on our application server from all these different terminals gets really slow when we're busy. The weird part is that sometimes it doesn't give us trouble when we're busy. We've talked to our application developer and he says we need to update all the machines to XP and run RDesktop 6 because it will optimize performance. Would the different versions of RDesktop be causing bad performance?
-
I'm not sure which category I should put this in, so I'll start here. We're running an application server with Win2003 on it. RDesktop 6.0 is installed on the application server, but the clients differ. Some of the clients are running XP (RDesktop 5.1-6.0) but the majority of our machines are running win2000, which only support RDesktop 5.1. The problem is that the application we run on our application server from all these different terminals gets really slow when we're busy. The weird part is that sometimes it doesn't give us trouble when we're busy. We've talked to our application developer and he says we need to update all the machines to XP and run RDesktop 6 because it will optimize performance. Would the different versions of RDesktop be causing bad performance?
Maybe its the different settings your users have. RDesktop can be configured for modem use up to LAN use (high speed). There's also a noticeable difference in speed if you're mapping dirves, printers, etc.
Todd Smith
-
Maybe its the different settings your users have. RDesktop can be configured for modem use up to LAN use (high speed). There's also a noticeable difference in speed if you're mapping dirves, printers, etc.
Todd Smith
Todd Smith wrote:
There's also a noticeable difference in speed if you're mapping dirves, printers, etc.
In my experience; only if you access them. Particularly drives.
-- Broadcast simultaneously one year in the future
-
I'm not sure which category I should put this in, so I'll start here. We're running an application server with Win2003 on it. RDesktop 6.0 is installed on the application server, but the clients differ. Some of the clients are running XP (RDesktop 5.1-6.0) but the majority of our machines are running win2000, which only support RDesktop 5.1. The problem is that the application we run on our application server from all these different terminals gets really slow when we're busy. The weird part is that sometimes it doesn't give us trouble when we're busy. We've talked to our application developer and he says we need to update all the machines to XP and run RDesktop 6 because it will optimize performance. Would the different versions of RDesktop be causing bad performance?
Why are you using Remote Desktop to run a client-server app? That's the problem. Ditch Remote Desktop and have the person build the application correctly. Seriously, why is it like that? It's not the different versions causing the problem, it's the fact of using Remote Desktop to connect your clients. It's a bandwidth hog, and naturally it's going to slow the network down. With a normal client-server application, you only want to transfer essential data back and forth. I would expect slowdowns if you had more than 4 or 5 people using RD to connect to the same server at the same time. It might slow the machine itself, and it would definitely clog the pipes going out from the server. Is there a reason why you are doing it this way?
"Quality Software since 1983!"
http://www.smoothjazzy.com/ - see the "Programming" section for freeware tools and articles. -
Why are you using Remote Desktop to run a client-server app? That's the problem. Ditch Remote Desktop and have the person build the application correctly. Seriously, why is it like that? It's not the different versions causing the problem, it's the fact of using Remote Desktop to connect your clients. It's a bandwidth hog, and naturally it's going to slow the network down. With a normal client-server application, you only want to transfer essential data back and forth. I would expect slowdowns if you had more than 4 or 5 people using RD to connect to the same server at the same time. It might slow the machine itself, and it would definitely clog the pipes going out from the server. Is there a reason why you are doing it this way?
"Quality Software since 1983!"
http://www.smoothjazzy.com/ - see the "Programming" section for freeware tools and articles.Jasmine2501 wrote:
Ditch Remote Desktop and have the person build the application correctly. Seriously, why is it like that?
It's not always feasible to rewrite your entire I/O backend to use a client/server architecture instead of the file system. Then RD becomes a viable solution. It's also nice for sys admins. ;P
-- Raaaaaaaaaaaaaaaaaaaaa!
-
Jasmine2501 wrote:
Ditch Remote Desktop and have the person build the application correctly. Seriously, why is it like that?
It's not always feasible to rewrite your entire I/O backend to use a client/server architecture instead of the file system. Then RD becomes a viable solution. It's also nice for sys admins. ;P
-- Raaaaaaaaaaaaaaaaaaaaa!
But it is always possible to tolerate poor performance caused by dumb application design. And SysAdmins are a necessary evil that contribute nothing to productivity in the enterprise.
-
Jasmine2501 wrote:
Ditch Remote Desktop and have the person build the application correctly. Seriously, why is it like that?
It's not always feasible to rewrite your entire I/O backend to use a client/server architecture instead of the file system. Then RD becomes a viable solution. It's also nice for sys admins. ;P
-- Raaaaaaaaaaaaaaaaaaaaa!
Yeah I guess I've seen that a lot - a legacy application that is bad to begin with and you just keep piling more bad stuff onto it until the whole system collapses. This is where you are at now - the whole system is becoming unusable. So you need to ask yourself if the company can continue to function with its key applications hobbled by bad design, or if you're going to bite the bullet and make the expense to fix the problem. If it doesn't get fixed now, it will eventually get fixed, and cost more. It's like letting your brakes go bad in your car... eventually the thing fails completely and you get in an accident and have all kinds of extra problems, and you still have broken brakes. This happens with every application an enterprise ever uses. Eventually it becomes unsuitable for the original task, unless the company never expands and never requires anything more than what it started with, and almost no company is like that. Also, new technology makes old ways obsolete, and so even applications that are designed correctly will eventually need to be replaced or massively overhauled. It is a fact of life for any industry that uses software. Good luck with this... you're in a tricky position.
"Quality Software since 1983!"
http://www.smoothjazzy.com/ - see the "Programming" section for freeware tools and articles. -
Yeah I guess I've seen that a lot - a legacy application that is bad to begin with and you just keep piling more bad stuff onto it until the whole system collapses. This is where you are at now - the whole system is becoming unusable. So you need to ask yourself if the company can continue to function with its key applications hobbled by bad design, or if you're going to bite the bullet and make the expense to fix the problem. If it doesn't get fixed now, it will eventually get fixed, and cost more. It's like letting your brakes go bad in your car... eventually the thing fails completely and you get in an accident and have all kinds of extra problems, and you still have broken brakes. This happens with every application an enterprise ever uses. Eventually it becomes unsuitable for the original task, unless the company never expands and never requires anything more than what it started with, and almost no company is like that. Also, new technology makes old ways obsolete, and so even applications that are designed correctly will eventually need to be replaced or massively overhauled. It is a fact of life for any industry that uses software. Good luck with this... you're in a tricky position.
"Quality Software since 1983!"
http://www.smoothjazzy.com/ - see the "Programming" section for freeware tools and articles.I am so aware of the situation... :sigh: