Latest Contributions by DavidHoy

Hi @DeanHowell1  In your particular case, where you have each tier separated and with multiple machines, each running one of the pieces - then yes - just shutting down the machine is fine. On startup, the windows services will restart themselves as well. The Lambda functions for shutdown and startup do need to be updated to include the specific order and some wait times. There are known problems when two machines in a tier (e.g. Portal) start at the same time. ... View more

but when the Enterprise configuration is HA with multiple machines, you need to be more careful. If a Primary Portal or Data Store machine is taken down, the Standby will try to take on that role. If the timing goes bad, you may get "split-brain" problems when the machines are brought back up. i.e. two servers both thinking they are "Primary". You need to check manually which machine is Primary and which Standby, then ensure the shutdown order is: Portal Standby Portal Primary Hosting Server(s) Any other Federated Server(s) Data Store Standby Data Store Primary then reverse for Startup Data Store Primary Data Store Standby Any other Federated Server(s) Hosting Server(s) Portal Primary Portal Standby  If this is to be scripted - you could call the REST endpoints to find the current status of the machines in each tier. There is also a need to wait for the individual processes (Windows Services) and associated GIS services to stop / start completely between each step ... View more

Jamal NUMAN‌ Have you had any success in improving the performance of the Map Service? To diagnose properly, we need to know a few more details: - does an equivalent service with the same data in a file data source work faster?    this may indicate data access problems from the server to the database - is the enterprise geodatabase in the same data centre as the ArcGIS Server? it is generally a bad practice to try to connect to an Enterprise Geodatabase (Oracle/SQL Server/PostgreSQL etc) via SQL clients across a high latency network each draw of an individual layer may require >10 sequential SQL queries - multiple layers compound the delay as they draw one at a time. with even (say 50ms query latency, you may be waiting many seconds for just the querying and return of results - before the rendering even begins. - does the layer draw faster in a desktop application (ArcMap or Pro) using a direct database connection rather than accessing the service? it may be that the path from the Server to the database may be slower than the Desktop client to the database - Are you seeing bad performance only when trying to draw many polygons? if your service is defined to draw lots of detail at small (zoomed out) scale, you may need to ask if the detail is relevant. You may be asking the server to render many thousands of individual vertices - even when these all are actually rendering to the same pixel on your screen! Lots of vertices = a large data packet returned to the server (transfer time + lots of server time rendering individual vertices redundantly in the map image) - Are you seeing slow draw even when zoomed in close and only showing part of one or a few polygons? This may also be a symptom of a too finely detailed polygon. You may benefit from simplifying the boundaries of you polygons to remove vertices that dont add relevant to the shape. Sometimes, you may only see a small part of the polygon's boundary, but unfortunately, the SQL query will still be returning the entire feature to be rendered. There are more possible reasons, but let's see how you go with this for a start. ... View more