GVH takes so long to start (two links are retrieved),
GVH takes so long to start (two links are retrieved), 
I observed that GVH takes so long to start.
The first period is spent while calling
http://geo.molg.pna.ps/L3/Index.html?viewer=A2.C1#gcx-SKCT-Z8eNfNEax3Ap_S9PbHwAAe0EFdljkmU-nf2dbZEG66wAAkWhIrGXqrX7fr6YwCbKqo0gm
the second period is in calling
http://geo.molg.pna.ps/L3/Index.html?viewer=A2.C1#
this delay is reported by users
what might be the reasons for this delay?
thank you
best
Jamal
0
-
We have the same issue and ahven't figured out exactly why. However we did have an analyst from ESRI examine our server set up and discovered that we are running too many map services (in ArcGIS Server) for the 4 cores our server currently has. I'm hoping that an upgrade will help resolve the issue but won't know for sure till that happens. I was looking to Geocortex for a solution but I think in our case it's our server environment that's causing the delays (and other performance issues). 0 -
@Rebecca: Just out of curiousity, how many services were you running on that server? Do you only have one server or a cluster? How many service processes were typically running? Were you using high or low isolation?
We are having some issues and I am starting to think we also have too many services going...0 -
We are consuming same services in Cityworks application and maps really start fast. Then, I guess that this issue in not related to Server capacity.
However, according to ESRI, the maximum number of ArcSOC.exe you can have at your server machine equals 5 multiplied by the number of cores.
0 -
Also, RAM required equal 3 multiplied the number of cores
For example, if you have a server of 16 cores, then- The maximum number of arcsoc.exe =16*5=80 ArcSOC.exe
- The minimum RAM size =16*3=48 GB
0 -
When I first converted our sites to HTML5 I came across a number of issues that were slowing things down. I don't know if these issues have been resolved in current version. Permissions were a large issue - I ended up getting rid of most of them. If you have many aerials, make sure to go into Map Services and remove all the subtiles. I'm sure I'm exceeding all sorts of ESRI guidelines, but the same site was displaying MUCH slower using the HTML5 viewer than the Silverlight viewer. I ended up making all new sites. My sites now are about equal in time to open. Sometimes the HTML5 sites feel slower, since there is little feedback to the user in the newer versions. I've also made a lightweight Parcel Viewer that opens much faster, but it has fewer aerials and many fewer services overall.
https://maps.srcity.org/Html5Viewer/Index.html?viewer=parcel0 -
Having a progress bar on the splash title screen might be a good idea to a give a feeling for the end user that the application is responding. If it just remains on that splash screen with no indication, then this might deliver a wrong message and might give a feeling that the application is frozen. 0 -
I'm finding that as folks stop using Silverlight, and more folks are using HTML5, my sites are getting slower. I'm assuming HTML5 demands more from the server than Silverlight. I've been playing around with AGS settings to speed things up - upping the Min/Max number of instances and lowering the Service Timeouts. This helps, but also requires more RAM. 0 -
@Dan - we were running over 60 services on one machine (4 cores) which was causing all kinds of problems. I was able to reduce that to about 40 but still way too much for our environment. There are dozens of ArcSOC services running much of the time which is maxing out the server resources. I'm surprised the server hasn't crashed. I changed some of the more popular services to low isolation on ESRI's advice but it didn't make a huge difference and now my ArcGIS server log files are full of errors although everything seems to be working - users are still experiencing poor performance at times. Planning to increase to 8 cores to see if that makes any difference but I'm waiting (and waiting) on IT to get that done. Increasing RAM is another issue we should likely be addressing. 0 -
@Rebecca - are you looking at the Min and Max Instances in AGS? I found that by playig with these values, I was able to get more performance out of my AGS server. If you go in to AGS and look at the Instances in Use, and if that is equal to your max, than you need to up your max. I also will up my min if the In Use value is above the min. Of course, this requires more RAM, but that tends to be cheaper than licensing more cores... When your site is loading, see what services shows as the last loaded - it is likely that by increasing the Min/Max for that service you will see faster load times. 0 -
Also, for those services that are not on by default at load time, it is good to keep those at the default Min/Max of 1/2. For my most used services, I set the Min/Max to 15/30. This uses up (reserves?) more RAM, so you only want to do this for the 3-5 most used services. What your actual ideal Min/Max will depend on usage, and that you can see by the "Instances in Use" value. 0 -
Thanks for the reply. You are in the same boat as us, although we have 4 machines in our cluster. The multiple machines doesn't seem to help much, as they all typically run the same number of service instances anyway. We are up over 60 services (almost all in low isolation), as well, and we always have log files full of errors. They all have 4 cores and 32GB of RAM. None of the servers really seem to max out, so I am not sure why we have so many issues. We do have to periodically restart our ArcGIS servers and webservers running the Webadaptor (about once every week or two). They just seem to get a couple bad instances sometimes and then become unresponsive. ArcGIS Server does not seem to do a very good job of recycling the instances or identifying and killing bad instances.
Good news is we are in the process of upgrading our infrastructure, so hopefully that stabilizes things.0 -
Thanks for the suggestion Mike. was just going on the vague advice given by ESRI. I did change a number of them (min/max settings) but your explanation makes much more sense. I also need to convince IT that we need more RAM. I seem to be getting push back on the RAM issue and I'm not sure why. 0 -
I'm in IT, so that makes it easier to deal with them...! My server tech keeps saying that while it looks like AGS is using a bunch of RAM, it is actually not, at least in our Virtual world. Apparently it is just being reserved but not actually used... Over my head. All I know is that it works faster with more RAM.
I've left all of my services as high isolation, since that was the recommendation in the ESRI help system.0 -
This is where the Statistics in Server Manager come in handy. It will give a decent picture of what services are used the most, so you can shift more resources to them. 0 -
We're still on 10.2.2 and I can't find anything about statistics. Maybe a new feature in more recent releases? 0 -
Not sure when it was implemented, but we are on 10.3.1 and it is under the Logs section. It gives basic info for each (or all) services like total requests, response time, and timeouts. 0 -
Many thanks guys for the rich input. This is very useful.
To which degree the viewer (GVH) plays a role in speeding up\slowing down the process or is it all related to the ArcGIS Server (services configuration)?
By default, each service generates 1 ArcSOC.exe as min and 2 ArcSoc.exe as max. where each ArcSOC.exe consumes at least 80MB from the RAM. According to recommendations, keeping around 20% of the RAM size free is good to keep server machine works fine and as expected.
0 -
They can both play a roll. In terms of the site, how many services you have makes a huge difference. If you check these two sites, the Parcel site below has only 4 services - a light-weight dynamic service that is on by default, a heavier contours dynamic service that is off by default, and then two cached aerials, one of which is on by default. Compare that to the other, which is fully loaded - 5 dynamic services (used to have fewer, but had to break them up because they had too many layers) and 17 cached aerial services, along with numerous layer themes. I've optimized both, in terms of getting rid of aerial tiles and permissions (anything that needed special permissions, a put into a separate light-weight site), so other things being equal, it is the number and complexity of the two sites that make the difference.
https://maps.srcity.org/Html5Viewer/Index.html?viewer=parcel
https://maps.srcity.org/Html5Viewer/Index.html?viewer=publiccity
That being said, the services themselves can be optimaized. Limit the number of layers (I think my biggest still has close to 200...), and make sure that any "slow" layers are not turned on by default. I ended up having to make my 1 foot contours dynamic to allow proper viewing on both hills and flat areas, but I leave that layer off. Likewise any layers that have many features along with joins and/or definition queries should be turned off. If the user needs them, they are there, but don't slow down the site open. Also, as you mention, each service by default has a min 1 and max 2 instances, and each creates an ArcSOC, but that is one way to increase performance without having to increase your number of cores - add lots of RAM, which is relatively cheap. For your most used services (or the last one to load on your site), up the min and max values. This uses RAM, but I've noticed a lot of improvement.0 -
Thank you Mike for the elaboration.
I think that there should be strong tools to measure the performance and to be able to decide where the bottleneck is! Software or hardware
Software:- SQL Server?
- ArcGIS Server
- Viewer (Geocortex, Cityworks, etc.)
Hardware:
CPU (Number of cores)
RAM0
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
Kommentare
19 Kommentare