Author: Eric Vasbinder
Vista Remote Link (VRL) is a powerful technology that allows for the Vista rich client to be run locally on a user's local workstation. There are a number of significant advantages to this mode of operations. However, when the rich client is running thousands of miles away from the server, there may be a performance decrease when using VRL. This most frequently occurs with those operations that have high levels of data validations, such as PR Timecard Data Entry.
There are two main categories where cloud performance may, depending on your network latency, be seen to be slower than on-premise. Remember, on-premise environments are routinely set up to have the clients effectively, "right on top" of the server with network latencies that are less than 10ms from the client to the server with very high network throughput.
Vista was originally designed for such a deployment. As such, even though great strides have been made to increase the efficiency of the Windows rich client of Vista to accommodate higher latency, slower network scenarios, there remain certain areas where performance will suffer when using the rich client connecting to a server hundreds of miles away.
The following are the two main categories we have seen in the past where performance with VRL over higher latency, lower bandwidth connections will be less than most on-premise installations:
This is where the end user sees "lag" when tabbing from field to field or entering a new line. For more details, see the section on Data Entry.
When using the built-in Crystal Reports Previewer, the navigation of the previewer, including moving from page to page could be noticeably slower than on-premise. For more details see the section on the Report Previewer.
AS MENTIONED ABOVE, DATA ENTRY TO VISTA OVER VRL IN OUR CLOUD ARE HIGHLY DEPENDENT ON LATENCY.
ANY LATENCY TO YOUR VISTA CLOUD INSTALLATION THAT IS OVER 30ms WILL RESULT IN NOTICEABLE SLOWNESS.
FOR OPTIMAL PERFORMANCE, THE LOWER THE LATENCY, THE BETTER - REMEMBER YOUR ON-PREMISE LATENCY WAS LIKELY ONLY 10ms OR LESS. PLEASE TEST YOUR LATENCY PRIOR TO GO-LIVE.
Some forms in Vista perform a large number of validations; validations require a sequence of back-and-forth data communications between the Vista client and the server. Unlike web browsers, rich clients often perform validations at the field level and the line level. As such, each one of these “round-trip” sessions adds time into process of getting data to appear in fields. When the round-trip is only a few milliseconds, like in a LAN environment or in RDP, 50-70 round trips is not a big deal; your server is literally only down the hallway. When the client is moved to thousands of miles away from the server, the network latency might increase to 60ms or more. This can often be up to 10 or 20x higher latency PER ROUND-TRIP. In that situation, each one of those round trips add up. This back and forth can cause problems with data entry performance in validation-heavy forms.
A great analogy is to imagine that Vista is a delivery truck. Imagine that the delivery truck has to make 50-70 deliveries back and forth between a retail store and the warehouse for each big item that is purchased. If the retail store and warehouse are just a half mile away, you can still finish rapidly, even if it is tedious work; the time it takes to go back and forth - the latency - is very low. However, now imagine that the warehouse moves one thousand miles away. Each round trip now takes much longer. All of a sudden, those 50-70 round-trip deliveries now add up real fast.
Given this, and given the fact that some users of data entry forms in Vista are quite adept at rapid data entry; so capable of quickly entering information, that this increase in network latency can cause data entry "lag". For them, manual data entry in Vista over VRL to our cloud could appear to be up to TWICE AS SLOW as on-premise LAN.
There are five forms / areas where we see a higher probability of measurable data entry lag today:
PR Timecard entry (field to field, and line by line)
FYI - We recommend using VP1 Field Management and HR Portal (HFF / Keystyle) instead of Vista for this
JB Progress Billing (field to field, and line by line)
FYI - We recommend using VP1 HFF / Keystyle instead of Vista for this
AP Line Item Entry (field to field, and line by line)
FYI - We recommend using VP1 Financial Controls (HFF / Keystyle) instead of Vista for this
AR Line Item Entry (field to field, and line by line)
PO Line Item Entry (field to field, and line by line)
FYI - We recommend using VP1 HFF / Keystyle instead of Vista for this
To enable your processes to be performed as efficiently as possible, we strongly recommend using modern tools to democratize your workflows, to allow for multiple users throughout your organization, from field staff to back office personnel to be empowered to enable activities such as time entry themselves.
Here are some options modernize your workflows:
Use Viewpoint's HR Portal and/or Field Management (formerly Keystyle, a.k.a. HFF) for time card entry
As these solutions are web pages and/or native mobile apps, validations are not performed in the same way, so data entry is faster.
A key additional benefit of this solution is that the time-consuming effort (even when data entry is rapid) of entering multiple timecards for all employees at once is eliminated
Timecard entry is democratized, rather than being forced to occur through a small number of payroll clerks
Use Viewpoint's Financial Controls AP Unapproved workflow for AP Line Item Entry and AP Approvals
As this solution is web-based, validations are not performed in the same way, so data entry is faster.
Use Data Imports
Using a CSV file to import time through Vista's time import mechanisms will avoid the slowness in data entry entirely.
Use RDP
In this specific situation, you would either set up your own AVD / RDP server in the same datacenter as Vista (managed by your IT team) (PREFERRED), or you could partner with our cloud support team to request RDP connectivity be set up for the specific users who except sub-millisecond response times in the forms listed above.
With RDP, Viewpoint hosts the Vista rich client on our Terminal Servers in our cloud, placing the client right on top of the database server, very much like it is done on-premise, this reduces latency to less than 1ms, thus increasing speed by up to 20x.
NOTE: There are functional down-sides with using RDP, including no drag and drop from local workstations, more difficult printing and scanning, etc. Due to these downsides we recommend that a limited number of "10 key experts" who require extremely rapid data entry in Vista forms be granted this ability.
NOTE: these users, if they use Microsoft Office integrated with Vista, would need to purchase Microsoft Office E3 licenses or higher for Microsoft Office to be hosted in our cloud.
Avoid Content Security and Cloud Firewall Solutions for Vista Traffic
You should exempt Vista from cloud security scanning, which can add a minimum of 30-40ms of latency by itself.
This includes tools like zScaler and Netskope
Here is a Vista Cloud FAQ article that will provide more details on this topic: Fixing Issues with Cloud Content Security Solutions
There are multiple ways to increase data entry performance, from reducing the number of deliveries (making the delivery process more efficient) to keeping the data as close as possible to the client even if it does have to move (geographical proximity).
Given those possible ways to increase performance, Viewpoint continues to enhance the efficiency of Vista operations, to shrink the number of actions behind the scenes to enter data. In addition, see below for a number of other options, including ways to modernize and democratize workflows to take advantage of the distributed nature and efficiency of our web browser-based extensions to Vista, which perform all validations on the server-side, keeping the number of round-trips very small.
As of Vista Version 2020R1, we have implemented our new Validation Service. Part of Speed Demon IV, the Validation Service uplifts some of the validation effort that is performed on the client and places it on the Vista app server, dramatically shrinking the impact of round-trips that need to be performed between the client and the server. In our preliminary testing, we have seen data entry performance improve by an order of magnitude. In many cases, this performance improvement is enough to allow for an acceptable end user experience. However, for some data entry experts, this increase is still not enough.
Trimble will be continuing to invest in data entry performance in various areas in Vista. We have several options under review to continue these improvements, but we cannot commit to any time frames due to being a publicly traded company.
In addition, for customers located in specific regions, Trimble can spin up additional regions in Azure to geo-locate your data closer to you, saving up to 30ms in round-trip time for data entry. This can improve data entry speed measurably. One example is adding an additional region for the Southwest US region, allowing customers in locations such as California, Arizona, Nevada, etc. to connect to a datacenter located in Phoenix, WEST US3, instead of Fresno or Tri-Cities area, Washington State.
This category of potential performance impact when using VRL is tied to the way that reports are generated with VRL. Specifically, with VRL, reports are NOT generated on the client itself, so the client will NEVER hold the actual data from the result set of the queries from the report. Instead, reports are generated on the app server and then sent as PDFs behind the scenes down to the client. The resulting PDF is then displayer inside the Crystal Web Viewer controls that powers the "Report Previewer".
Unfortunately, due to the design of the VRL Crystal Report previewer, it does not download the entirety of the PDF file from the report, but only the displayed page. Then, when the user clicks on the "Next Page" button on the crystal reports previewer, the previewer cannot display a locally cached next page of the report. Instead, the previewer puts in another request for the next page of the report. The Vista Crystal Report engine on the app server will then generate that next page and send it down to the previewer.
In situations with high latency, low bandwidth, or both, this becomes problematic when users, who are accustomed to rapid paging between report pages, experience "lag" when going from page to page.
There are a couple of ways to work around performance concerns with the report previewer.
A quick and easy way to increase performance of report page turning in the cloud is to avoid the use of the Crystal Reports Previewer in its entirety. This is done by, from the reports launcher / parameter window, choosing to export the report to a PDF and then saving it to the user's local workstation hard drive. Once saved on the user's local workstation, the user can then open the file with Adobe Acrobate Reader and then page through the report with ease and rapidity.
This option will force the client to download the actual data to the local workstation over VRL, instead of the pre-generated report from the app server. This may, in some circumstances, result in improvements to report previewing page turn performance.
This method switches the local Vista client from using the VRL method to using the LAN connection method that is familiar to customers from on-premise usage. This method has the advantage of downloading the totality of the dataset of the report to the local workstation and then locally rendering it.
In this specific situation, you would set up your own AVD / RDP server in the same datacenter as Vista (managed by your IT team) (PREFERRED). This would have dramatically reduced latency and much greater bandwidth, significantly improving report page turn speeds in the report previewer.
You could partner with our cloud support team to request RDP connectivity be set up for the specific users who except sub-millisecond response times in the forms listed above. They would have their Vista client side application hosted in our RDP servers.
Changelog
Monday, 25 August 2025 at 10:52PM:
significant article re-work, clean up, modernization, and addition of a new section specific to Report Previewer page turn performance.
Tuesday, 21 June 2022 at 02:44PM
Included link to performance and network latency tests and reminder to see if your current used datacenter is actually the fastest one as we have two new datacenters.
Updated: Thursday, 25 March 2021 at 09:42PM
Post date: Jul 23, 2020 6:42:28 AM