I am in the process of migrating from ArcGIS server 10.2 to 10.4 on a strict timeline for forced server migration and I am finding that the same services when republished on 10.4 with identical hardware resources take 100 to 150 times longer to publish, like going from 5-10 seconds in ArcGIS 10.2, to 10-15 minutes to publish in 10.4. If publishing was something that was a do once and forget about it process this would not be a problem, but with 10.4 the services actually stop responding when republishing a service and during emergencies we sometimes have to make changes and republish hundreds of times and the downtime is not acceptable. We have some services using local paths, some using SDE, and none using UNC paths. Publishing for all of them on 10.4 is slow, though the services using data in SDE are most affected as they were the slowest to start with, though it is too slow even for the ones that only use local data.
Any ideas what might be causing this?
The only other thing I can think of that changed is the Server OS, which is now Server 2012 with AGS 10.4 vs Server 2008 R2 with AGS 10.2. Some of the sde data was reloaded in a new spatial data standard and it came to my attention that all of the new datasets after reloading are of Geometry spatial data type rather than binary in SDE since ESRI made that the default data type once the database was upgraded last time. I have seen the problems people are having with performance with the geometry spatial data type, which could be causing some of my sde slowness, but even the services not using SDE publish much slower.
Thanks for any ideas you may have!
Solved! Go to Solution.
Just to throw this out there, and possibly eliminate it as an issue....do you still have access to the old SDE, or was it already trashed? If so, you could try a service with the older connections/SDE environment to see if that is the cause.
Beyond that...I'm going to keep an eye on what others have to offer.
We are still using the same SDE server and the geodatabase is still at 10.2. The SQL server used by SDE is also one that falls under the mandatory migration and is next priority to get migrated, but it hosts multiple databases so I have to be careful and make sure there is not too much downtime for the non-GIS applications when it gets migrated, which will hopefully be at the end of this week. My most critical service does not use any SDE layers or UNC paths and publishing on it was still extremely slow compared to 10.2 but the services that do use SDE are downright glacial when publishing. Thanks...
In my experience that is no difference between publishing in 10.4 and any other versions.
If you just take one layer on local disk and publish it – does it take more than a few seconds?
What about image service?
If you opened the published mxd in ArcMap 10.4 does it takes longer (basically the server just open the mxd)?
We had one problem that when the SDE have many layers then both ArcMap and the server takes longer to connect for the first time because it loads more metadata into memory.
Try to isolate the problem for one data source.
Due to the bug above, do you at least have the ability to upgrade to 10.3.1?
Can you stay at the 10.2 for now until this bug is fixed, if it is the only problem that is causing your slowness?
A bug I cannot keep my current server due to Federal requirements,as it would be permanently quarantined if it is still running past the deadline with Server 2008 R2 . I have since run into some other show stopping bugs with no fix in ArcGIS 10.4, so I will scrap AGS 10.4 and downgrade hopefully to 10.3.1 I don't really have time to start over from scratch so I will attempt to uninstall leaving as much in place as possible and install 10.3.
I noticed the 10.4.1 upgrade was available so I installed it for both Desktop and Server products on the test server. If anything, it got worse and the other bugs were not fixed either. I tested the slowest of the services and it took 20 minutes and 7 seconds to publish!!! I do not have an accurate number on how much service downtime that resulted in but will test some more tomorrow before I uninstall 10.4.1 completely and try 10.3.1.
I talked to ESRI tech support and they confirmed it was a known problem and that the developers are working on it. I am still waiting to hear back about the other bugs. According to their reports, the problem did not exist in 10.3 though I do not know if the other show stopper bug(for us at least) exists in 10.3.1. I have no way of knowing the timeframe for the patch release so I am going to go ahead with the 10.4.1 uninstall and test 10.3.1 so we can try to move forward. With all the custom apps involved, bureaucracy involved in getting new machines on the network, and dealing with licensing; migrations are non-trivial so we may not do another for a couple more years and I would at least like to be at 10.3.1. Thanks to all who replied!
The correct answer is the bug post, but I don't feel like I can mark as answered/green a problem that has no solution. It seems like the forum needs a second status of yellow to mark as answered but no solution.
Thanks for this post on 10.4.1. We are still on 10.2.2 and planning to test for 10.4.1, and I'll report back my results if I have anything to add.
As for the "yellow flag", I agree that a "on hold" would be good for ongoing/unresolved issues like this, but problem is that things tend to stay out there forever, even if they should be cleaned up. So, that is my thought on why they don't have that....marking is a "assumed answer" may be your best bet for now, and bookmarking it to return later. But it may be that Timothy Hales or Christopher Catania night have some other solutions. Not trying to hyjack or get this discussion off track, but just in case there is a flag option I'm not aware of....