Optimizing Vista Cloud Performance

During repeated import processes, import-related tables can often grow substantially, especially when import batches are not closed in the rush of an average work day.  If these tables grow too extensively, import processing in Vista will slow measurably.  Specifically, if the IMWE or IMWENotes tables grow to exceed 100,000 rows or higher (plus or minus a few 10k rows), import performance will suffer, sometimes slowing to only a few records every second or less.

To that end, we highly recommend purging the IMWE tables.  This can be done either using the built-in forms in Vista to purge those import jobs, or by running SQL commands to manually purge the tables.

For your convenience, we have included a sample purge script that can purge your IMWE table in the event that you need to manually purge this table; see the following collapsable section.

IMPORTANT - THIS SCRIPT IS PROVIDED FOR THE CONVENIENCE OF OUR CUSTOMERS AND PARTNERS AND NO WARRANTY OF ITS EFFECTIVENESS OR SAFETY IS MADE.

YOU ARE RESPONSIBLE FOR ANY ISSUES THAT MAY ARISE FROM THE USE OF THIS SCRIPT.

Please review this script with your SQL server experts or consultants prior to use.

For the most part, Trimble Viewpoint does not recommend the use of custom triggers in Vista as they can cause database performance issues.  Thus, though it is possible for a customer to set up custom triggers and we still allow this use case, it is not something we recommend.

If you notice slowness with batch job processing, please ensure that and custom triggers that you may have are not interfering with the batch job.  If they are part of that process, consider simplifying them or removing them entirely.

Some of the immense power of Vista can be see in its highly flexible notifier system.  This capability allows for various workflows to result in notifications, such as email messages, to be sent when certain activities are completed within Vista.  For example, payroll notifications with check stub / payslips, notifications on new jobs being entered, job status changes, AP approval requests, and more.  However, along with the power of this capability, we can also see performance impacts depending on the size, number, and complexity of the notifications configured in any particular Vista system.

If there are too many custom notifiers, or if they are running against too many simultaneous records, or if they are themselves too complex in their queries and actions, they can cause slowness in Vista batch processing, including payroll, check printing, etc.

Whether you have this issue or not, please methodically review your custom notifiers in service today to ensure that only those notifiers that are necessary for your business critical workflows are in use.  In addition, please consider reducing the complexity and / or scope of those critical notifiers to include only that which is needed for those notifiers to accomplish their tasks.

One final item to additionally consider is that if notifiers are using custom queries, those queries themselves may be written using older, inefficient SQL code (see above section on using modern SQL code designed for SQL 2019 or higher).  If so, they can dramatically slow down the system when multiple notifiers are being executed simultaneously.  Please update your critical notifiers to use modern SQL code where possible.

Some custom Crystal Reports were originally written with queries that are optimized for SQL 2012 and older.  This creates a potential performance issue when moving those reports into our cloud environment, which uses much newer versions of SQL server.

As such, if, when running Crystal reports in the cloud, you notice either high CPU usage in our dashboards, extremely slow report performance, or slowdowns in the rest of Vista while a report is running, please reach out to Viewpoint support staff to verify if long-running or blocking queries from your Crystal report are causing the performance issue.

If confirmed, please consider rewriting that report to be more compatible with modern SQL server query execution plans.

Ensuring that document attachments stored in Vista are no larger than necessary is a significant best practice to assisting with the speed of uploading, printing, and downloading attachments.  The following URL shows some specific recommendations on how to accomplish this task:  Optimizing Attachment Size 

A good rule of thumb is that PDF attachments should not be more than 15-20kb per page.  If you find that your attachments are significantly larger than this, you may wish to change the settings used to save  your PDFs to optimize their size further.

The Vista Remote Link (VRL) technology used in our Viewpoint Vista cloud is very latency sensitive.  As such, keeping your network latency as low as possible is a desired goal.

To that end, if you see performance issues with data entry or moving from page to page in reports, etc. you should validate that your latency is as small as possible.  Here is a link to a cloud FAQ article that walks you through testing your network's latency to determine if you have excessive latency or packet loss.

Network Standards for VRL Cloud Connections and Testing Them 

In some cases, local office wireless networks are set up in a "mesh" or repeating deployment model.  This method, though effective at extending wireless range and capacity for standard email and web page browsing, increases network latency by a significant amount.  As such, it sometimes occurs that using cloud-based VRL Vista on a wireless network is slower than ideal.

To that end, where possible, such as an office location with discrete desks for end users, we recommend the use of hard wired networking, which can sometimes increase Vista VRL performance by 25% or more for particularly "chatty" workflows in the client.

Our advanced Trimble Viewpoint cloud for Vista has multiple regions where Vista may be hosted.  One key reason for this, beyond redundancy, is to be able to bring the Vista database as close to your 10-key experts as possible.  As data entry in Vista is extremely sensitive to latency, we recommend testing your latency to determine the fastest supported location for Vista and, if there is a datacenter region with latency that's at least 10ms smaller, moving your Vista environment to that region.  

Once you have identified the fastest region for your 10-key data entry experts, please submit a cloud support case to have your environment moved to the faster region.

Please remember to try this test with any cloud content security solution both turned on and turned off, making note of any difference caused by the use of those tools.  See next section below for more details.

Please see this FAQ for the supported regions and methods to test.

Network Standards for VRL Cloud Connections and Testing Them 

Cloud-based content security solutions, such as NetSkope and zScaler can provide organizations with a robust way to limit the possibility of data exposure to third parties by blocking the sending of sensitive data to external sources.  These tools have become more commonly used as "zero trust" models for security implementations become more commonly used.

Unfortunately, the current technology of these cloud content security solutions (a.k.a. "cloud firewalls") can significantly increase latency for Vista traffic.  Remember, these tools route all HTTPS and HTTP traffic through the vendor's network in the cloud, decrypting your traffic to scan it for problematic data disclosures and embedded threats, then reencrypt the traffic for delivery to the final destination.    As mentioned above, higher latencies can cause significant negative performance impacts to the Vista end user experience.

In more detail, since Vista VRL traffic has to not only be delivered to the Vista VRL proxy server in our cloud, it also has to return to your client, the impact could be significant.  Imagine a standard 15-20ms latency increase by using NetSkope or zScaler, which is what we might expect.  Since we need to both send and recieve data, now with a 20ms or so delay, we see an overall increase in latency of 30-40ms for each call made by the client.  Since heavily validated Vista client forms require 20-30 back and forth calls to move forward, this can add up to nearly 1.2 seconds or more of lag.

To rule in or out these solutions, please try temporarily turning off your cloud content security solution and performing appropriate testing of Vista workflows. 

To that end, we recommend putting in exceptions for data destined for the Trimble Viewpoint cloud to exclude it from being routed over the content security provider's cloud.  

Instructions on how to do so may be found by reaching out to the vendor of your cloud content security product.

Paging is a powerful technology in the Vista rich client that allows the client to load only the minimum number of records into the grid as needed.   This can significantly improve form load times, especially on forms with thousands of records.  It will significantly reduce the amount of time it takes to load those forms, while still preserving the behavior of the grid filter bar and form search functions, still allowing you to search through the totality of the data set. 

The following Cloud FAQ article provides instructions on how to enable paging.  Please ensure paging is turned on wherever possible - it was one of the three "pillars", set up as a means to ensure the success of VRL for our customers.

Enabling Vista Paging 

Many workflows in the Vista rich client are also available in our Vista Web portal and native mobile apps.  These tools, formerly known as HFFS or Keystyle, perform validations and other operations in a completely different way as compared to the rich client.  This allows for rapid, near-zero lag data entry among other improvements.  We have continued, and will continue, to uplift functionality, where appropriate to the Vista Web solution, allowing our customers to experience a more performant cloud world.

To that end, where possible, we recommend democratizing and modernizing your processes to leverage Vista Web's capabilities as much as possible.  For example, where possible:

• Time card entry:  should be performed in the Vista Web (HR) portal or via the Field Management native mobile apps

• AP Entry and approval processes:  should be performed through the Financial Controls portion of Vista Web

  • Both full AP Header entry and line item entry as well as approvals can be performed through Vista web today

Certain data entry operations in Vista, such as Material Sales Ticket Entry are not replicated in Vista Web and can sometimes encounter lag during heavy data entry, especially if your network is distant from the Vista database.

In these scenarios, we recommend the use of CSV file imports via the autoimport process into Vista.  Your external systems (i.e. Third party integrations), as well as human end users, can enter data into CSV files that can be manually imported via the IM Import form or by placing the files in the Viewpoint Repository's pickup folder (AUTOMATED SERVER TO SERVER IMPORTS ONLY).

This will avoid any data entry lag, as data is either entered by an end user on their own local workstation or automatically from a third party integration.

Corporate client-side VPNs can often slow down VRL access by adding unnecessary, additional hops onto the network path, similar to a GPS routing a car through a dense, residential neighborhood, rather than directly on to the expressway on ramp.  

As such, when using any client-side VPN on your workstation, we highly recommend turning on Split Tunneling to ensure Vista related traffic proceeds as rapidly as possible to the datacenter.

Here is a link to an FAQ article with much more detail on split tunneling and its potential performance improvements:  Cloud Vista using VRL with Client (SSL) VPNs - Split Tunneling Recommended