Making a Fat Client Application Run Like a Sprinter

One of our Dynamics SL customers asked us to help them tune DSL to run faster over a wide area network serving several locations in the US, Europe, and China. After several meetings with their IT staff, our practice manager Jason Hull and our IT professionals, here is how we made a fat client run like a sprinter.

Traditional 32-bit client-server applications like Dynamics SL use a small client that is installed on a workstation. It is a few DLL files and other Windows components, and depending on the application, a client executable. All of the screen executable and report files reside on the server. That means opening the menu, opening a screen, running a report; all generate a significant amount of network traffic. The screen is passed across the network from the server and runs on the user’s PC. All data is pulled from the SQL server. Whenever an operation occurs, huge amounts of data are passed back and forth to the server.

If you have, a remote client connected via VPN, it is going to appear as part of your network and it is possible to run the client on that workstation and pull all of the screens and reports across the internet. This is usually incredibly slow because of the significant amount of traffic that is generated. That traffic is not optimized for internet delivery, unlike video streaming services such as Netflix for example, which use advanced compression algorithms to really minimize the amount of data that is transmitted.

Modern web-based applications like Acumatica or Dynamics 365 are built for this highly distributed type of deployment and use a much thinner web-based client, so they are much more bandwidth efficient. Dynamics SL, GP, NAV, Sage or even QuickBooks installed locally are never going to make the most efficient use of the internet, that is why Windows apps are called fat clients and web apps are called thin clients.

The best solution today is some sort of remote desktop solution that, instead of sending all of those large executable and report files plus data across the internet, only sends images of the screen and mouse movement/keystrokes. This traffic is designed to be bandwidth efficient, with only the changes in the screen being sent instead of the entire screen, etc.

That being said, just installing the client on a terminal server is often not enough to provide users with really good, workable access to the application. There is a lot of optimization that can be done to minimize bandwidth. There is always going to be some network latency to contend with, and the more connections there are between the server and the user, the slower the connection is going to be. That is why streaming services utilize a global network of servers to get the server as close to the user as possible to minimize latency. That is not possible with SL or similar applications, so we have to concentrate on the two areas we have control over. The speed of the remote desktop server and bandwidth efficiency. Here are our recommendations:

  1. The remote desktop server needs to be configured to run as fast as possible. This means at a minimum, ample memory, and processors. You want the fastest possible connection between the remote desktop server and the database server. Ideally, they are on the same subnet with a very fast (at least gigabit) switched connection between them. Installing Solid State Drives in the remote desktop server can also greatly increase performance as well.
  2. On the remote desktop server itself, it is very beneficial to performance to do a complete install of the application program files and reports rather than the typical client install. This greatly speeds up the time that the server is able to load screens. The only caveat to this is that updates, third-party add-ons, etc. have to be installed in two locations instead of one. Custom reports also have to be maintained in both places, but it is easy to automate this process.
  3. On the bandwidth side, the settings need to be optimized to reduce the color palette to the minimum. Sending 16 bits of color data consumes roughly half the bandwidth of sending 32 bits of color data. Sound can be turned off completely.
  4. Another tactic that can be employed is to take advantage of published applications.  Instead of broadcasting an entire Windows desktop across the internet, only the actual SL application is shared. The benefits are twofold. First, the application runs in a seamless environment directly on the user’s desktop just like it would if the client were installed locally. Therefore, this provides a better and easier user experience. Second, it greatly reduces the bandwidth required because you are sending fewer screen data- small windows instead of the entire desktop.
  5. Finally, Citrix has some solutions that run on top of Windows Remote Desktop that can provide further bandwidth optimization. Citrix even has its own network protocol that is more bandwidth efficient than the Windows RDP protocol.

The good news is, with the exception of Citrix, all of this can be done with little to no additional software and can provide a tremendous increase in speed for remote users. If you would like AccuNet’ s help fine-tuning your applications performance or our practical experience for any application or network challenge, contact Michael Milligan at [email protected].

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>