POST
|
Hello, Please refer to High Availability in ArcGIS Enterprise . Pay very close attention to the prerequisite environment requirements. If you even think that you may not meet the prerequisite requirements don't use Portal HA. In the past, my attempt to use Portal HA in my datacenter computing environment created LESS availability and MORE administrative overhead because the data transport timing tolerances for Portal HA communication were mismatched with my actual computing infrastructure performance and availability. I reverted back to a single Portal in non-HA and INCREASED availability. Not quantitative data, but I've spoken to no less than three other ArcGIS Enterprise administrators that have also realized LESS availability in their environments with Portal HA. In a perfect world with a perfect supporting computing environment Portal HA might work great. I accept the real world over the perfect world though.
... View more
04-18-202203:55 AM
|
0
|
0
|
60
|
POST
|
JoshuaBixby wrote: " As an IT service provider, I have had many battles with lazy GIS staff who don't want to take the time to craft a high-performing map, but then somehow expect ArcGIS Enterprise to work miracles and turn it into a high-performance service." Amen to that brother.
... View more
10-15-202108:36 AM
|
3
|
0
|
842
|
POST
|
Hello, My environment: ArcGIS Enterprise 10.8.1 hosted on 2 physical Windows servers. Server 1 [Portal, Server (federated, hosting); Server 2 (Server, Data Store (relational)] I have 300+ services. I did "step up" the heap size in registry once when we hit about 200 services. That worked fine. Concurrent with this change was migration of "simple" and/or low use services to shared instance. The shared instance use somewhat reduces the need to modify heap size in registry because the total number of SOC.exe processes is reduced. TIP: Before trying any of these "tuning" techniques, evaluate your computing environment and ensure you are provisioned for current and anticipated system loading. Each of my servers has 192GB of RAM and 2x 24 core processors. These resources allow setting the shared instance parameters pretty high thus reducing the total number of dedicated instance service I have. As far as your future plans with Portal: Suggest view ArcGIS Enterprise as Portal/Server/Data Store not as individual pieces. By implementing Portal and Data Store, we have overcome many performance limitations and/or resource "tuning" requirements inherent with Server only implementation. Hosted feature services really "live" in Portal/Data Store. All Server is doing is creating the service end point. Perhaps an over simplification. Hope it helps. Read between the lines: If you consider the interaction between ArcGIS Web GIS components and ArcGIS Enterprise, the writing on the wall tells me that it the not too distant future, ArcGIS Enterprise will be Portal and Data Store. No more Server. Lastly, if you don't want to bother with the Windows OS "tuning" and you can choose your OS (unfortunately I cannot), host ArcGIS Enterprise in Linux instead of Windows. You'll require less computing resources for the same performance level and, in my experience, it just works without an overabundance of administrative care and feeding. Yes setup is somewhat more involved but again, in my experience, worth the initial investment.
... View more
10-15-202102:42 AM
|
2
|
0
|
968
|
IDEA
|
Good idea. A typical use case is administrative boundaries seen at small scale/large area and imagery at large scale/small area. This functionality is particularly desirable when creating basemaps for use in Field Maps and other mobile Internet disconnected workflows. The blend settings in Map Viewer don't currently allow the desired functionality.
... View more
10-08-202103:57 AM
|
0
|
0
|
436
|
POST
|
Hello, 1st, I don't know the answer to your specific question. I would like to share some thoughts though on low latency considerations for IT and ArcGIS Enterprise optimization. 1. Any introduced latency to communication between applications and data stores is bad. 2. Encryption and decryption introduces data manipulation and increases latency. 2a. Suggest, instead of encrypting a single communication path from RDBMS to ArcGIS Enterprise you evaluate your entire LAN/WAN information protection and information assurance posture and choose the most limited data manipulation plan that meets your organizational goals without the "overhead" of individual connected resource encryption if you can. Very generally speaking, firewalls, network hardware encryption and software security monitoring and encryption is not a GIS Enterprise's friend. Quite required for overall information protection and assurance absolutely. Impact to overall Enterprise GIS architecture and service performance. Also absolutely. Want to see for yourself? If you have the resources, set up ArcGIS Enterprise in a secure isolated environment without any add on security components and measure the difference in performance compared to that most of us are constrained to use in a production environment.
... View more
09-17-202105:47 AM
|
1
|
0
|
303
|
POST
|
Good to know there is another workaround. Not practicable for our enterprise. We have hundreds of services and over 30 publishers.
... View more
09-15-202101:16 PM
|
1
|
0
|
836
|
POST
|
Please see same reporting.
... View more
09-15-202101:07 PM
|
0
|
0
|
949
|
POST
|
Please see Same reporting
... View more
09-15-202101:03 PM
|
1
|
0
|
585
|
POST
|
Same. First reported to us 2021-09-09. 1st stop was AGOL Health Dashboard . All green still green. We've opened our own case with Esri tech support.
... View more
09-15-202101:00 PM
|
0
|
2
|
856
|
POST
|
我的环境:ArcGIS企业10.8.1图像放大e server. We use a hybrid approach based on many of the points you've made. Sometimes we have multiple MDS in single FGDB and sometimes a single MDS in single FGDB and sometimes a single FGDB with a single MDS that is build from other MDS as the input source. Like almost everything we do in GIS data management, the end use case dictates how we decide to package those data and create services from it. For example, we categorize our orthoimagery collections in four overarching areas: Regional, Municipal, Conservation, Coastal. We have a single FGDB for each overarching category with multiple MDS based on collection year. For discovery/catalog purposes we have a single FGDB and single MDS including our entire ortho collections. This FGDB MDS has no overviews and is not for visualization, just for discovery of the tile/tiles that cover a spatial or temporal extent. This service is also the input to our tile discovery and download application. The key to make this work: Attribute your MDS with temporal information and enable time in your services.
... View more
09-09-202101:33 PM
|
1
|
0
|
718
|
Title | Kudos | Posted |
---|---|---|
1 | 03-04-202102:55 AM | |
1 | 07-22-202104:56 AM | |
1 | 09-15-202101:16 PM | |
1 | 09-17-202105:47 AM | |
3 | 10-15-202108:36 AM |
Online Status |
Offline
|
Date Last Visited |
07-26-202211:19 PM
|