Portal for ArcGIS 10.6.1 slow after upgrade and troubleshooting

2025
2
Jump to solution
11-26-2018 12:12 PM
MichaelSchoelen
Occasional Contributor III

After upgrading from Portal for ArcGIS 10.5.1 to 10.6.1 on Windows Server 2012 R2, we noticed significant performance delays when using Portal. Loads were taking almost 5x the expected time.

This is a high-availability "single machine" deployment, and only Portal was experiencing issues, meaning accessing the server admin site was a breeze with no problems. 

Re-indexing, installation repairs, dropping to a single machine, and adding resources did not help. There are no apparent log issues.

1 Solution

Accepted Solutions
MichaelSchoelen
Occasional Contributor III

We found the solution in a blog post from 2015 from Esri UK:

We have found that if Portal for ArcGIS is installed on a machine that has more than one network adaptor set up, users can experience performance issues. 

The problem is isolated to slow running requests going to Portal's PostgreSQL database. This can be checked using your browser's development tools. 

To check if this issue affects your Portal for ArcGIS site, log in to the site and browse to 'My Content' whilst using the browser's network trace tools. Look through the network calls that are being made and find the one that includes a token in the request. For example:

http://<machine name>/arcgis/sharing/rest/portals/self?culture=en&f=json&token=<token>

Copy this link into a new browser tab and monitor the request time. If the request takes more than a few seconds then try the workflow below.  

  1. Browse to your network adaptors by typing 'Network and Sharing Center' and clicking on 'Change adaptor settings'
  2. If more than one network adaptor is displayed, right click the primary adaptor and select 'Properties'
  3. Select 'Internet Protocol Version 4 (TCP/IPv4) and select 'Properties' and click 'Advanced'
  4. Untick 'Automatic metric' and enter '1' for the 'Interface metric'
  5. Select the Gateway under 'Default gateways' and select 'Edit'
  6. Untick 'Automatic metric' if ticked on and enter '1' as the Metric value

Setting the metric value gives the primary network adaptor priority over the other network adaptors. Browse through your Portal for ArcGIS site and see if this improves the response times.

View solution in original post

2 Replies
MichaelSchoelen
Occasional Contributor III

We found the solution in a blog post from 2015 from Esri UK:

We have found that if Portal for ArcGIS is installed on a machine that has more than one network adaptor set up, users can experience performance issues. 

The problem is isolated to slow running requests going to Portal's PostgreSQL database. This can be checked using your browser's development tools. 

To check if this issue affects your Portal for ArcGIS site, log in to the site and browse to 'My Content' whilst using the browser's network trace tools. Look through the network calls that are being made and find the one that includes a token in the request. For example:

http://<machine name>/arcgis/sharing/rest/portals/self?culture=en&f=json&token=<token>

Copy this link into a new browser tab and monitor the request time. If the request takes more than a few seconds then try the workflow below.  

  1. Browse to your network adaptors by typing 'Network and Sharing Center' and clicking on 'Change adaptor settings'
  2. If more than one network adaptor is displayed, right click the primary adaptor and select 'Properties'
  3. Select 'Internet Protocol Version 4 (TCP/IPv4) and select 'Properties' and click 'Advanced'
  4. Untick 'Automatic metric' and enter '1' for the 'Interface metric'
  5. Select the Gateway under 'Default gateways' and select 'Edit'
  6. Untick 'Automatic metric' if ticked on and enter '1' as the Metric value

Setting the metric value gives the primary network adaptor priority over the other network adaptors. Browse through your Portal for ArcGIS site and see if this improves the response times.

JianLiu
New Contributor III

Hi Michael, 

I'm seeing the same 10.6.1 performance issue (on 2012 R2), and found your post here. Thanks a lot for sharing the info. I tried the approach on two of our machines, one seems to pass but the other won't start properly after the change, so I had to revert it back. A support analyst from ESRI Canada commented this is a risky change and not recommend it, not know why. Nonetheless, this doesn't seem to improve the performance even on the machine where it passed. 

I saw your other post here: 

https://community.esri.com/thread/229858-frequent-the-database-server-was-found-to-be-stopped-re-sta...

And I have exactly the same error logs as you showed. Just wonder if that could be the actual fix for the performance issue?  We don't have Carbon Black Sensor though, and still need to track down what's causing the issue.. Thanks a lot for sharing the info.