|
POST
|
Absolutely, an we would like to leverage AD as well. It's definitely a priority for us moving forward and I will certainly post back any info/results to this thread...
... View more
06-11-2015
06:45 PM
|
0
|
0
|
3058
|
|
POST
|
That's fine George, I was not unclear. We purposefully moved to SQL Geometry at 10.0. I am simply trying to explain to the community that spatial index levels and number of cells per level does have a performance impact. We were able to solve that impact by tuning our levels and counts and I am just trying to pass that info along. David
... View more
06-10-2015
12:57 PM
|
0
|
0
|
2706
|
|
POST
|
Sure I understand. We define all of our storage parameters upfront in our dbTune tables for location, type, page fill params, spatial index params and more and assign that to a VECTOR keyword. Whenever we import or otherwise create data we simply use our keyword and in that way we are consistently set up across all of our user instances. We moved away from SDEBINARY storage at 10.0, and after initial struggles isolating our performance issues (disk raid config, san vs local array, network I/O, indexing) using SQL GEOMETERY storage, found that the spatial index parameter adjustment had by far the greatest impact on our performance. For example, our parcels layer was never super speedy even stored as sdebinary, but was initially terrible at sql geometry. After eliminating disk R/W, network I/O, memory paging, sql system database locations (esp temp db), primary and secondary data file storage locations and transaction log settings we found that the resetting the spatial index levels and cells per object greatly increased our desktop performance when usgin SQL GEOMETERY. David
... View more
06-10-2015
10:45 AM
|
2
|
0
|
2706
|
|
POST
|
What I mean is that when I publish a gp tool, I make sure the mxd itself and the data connections (or database in the case of a fgdb) contained in the mxd reside in the registered data store location...
... View more
06-09-2015
11:55 AM
|
0
|
0
|
4477
|
|
POST
|
Aaron - what do you mean 'The fact remains that SDE performance was better at SQL2008R2.'? We have not found that to be the case at all, in the fact the opposite. I replied earlier in this thread that tuning the spatial indices from the default Medium and 16 cells per level setting at all levels did not work well for complex polygon layers with lots of vertex and area variability. For these layers, we did find that index of Medium, Medium, Medium, Low with 64 cells per object greatly outperforms the default setting at both SQL2008 and 2012. For point and polyline layers, we found no impact in draw and query times between our adjusted levels and cells per object and the default setting. David
... View more
06-09-2015
11:51 AM
|
2
|
9
|
2706
|
|
POST
|
Are you sure everything is running from a registered location? Are you getting a clean result from the results window in ArcMap from which to publish the tool?
... View more
06-05-2015
12:10 PM
|
0
|
2
|
4477
|
|
POST
|
Hi John- What we do is set up a QA version below our DBO.Default, then create child versions off of the QA version named something like DBO.WebEdits. Using an editor role previously defined in our sql sever 2012 database, we then add the domained arcgisserver account to the editor role. On the back end then, all the edits made through the feature service are actually made by the arcgissever account. We handle editor tracking by enabling ownership-based control on the feature service, so that on the front end the edits to the feature service are made by users from our ArcServer user store assigned to a user role that has write access to the feature service. We then run a nightly python script to push edits from our WebEdits version to QA and then push QA edits up to DEFAULT on a weekly basis. David
... View more
06-01-2015
11:48 AM
|
1
|
0
|
2307
|
|
POST
|
Paul, its not that AD was unstable for us, its that we in GIS don't have any control over our AD and thus it was difficult to manage effectively. For us, using GIS tier authentication gives us more fine grained control as we have fairly restrictive AD policies and so it didn't make much sense for us to try to mix AD with the bult in roles. Also, our AD roles just weren't set up with server in mind, but rather for pure internal R/W access to various shares, etc. David
... View more
05-31-2015
12:10 PM
|
0
|
2
|
3058
|
|
POST
|
Hello all- The ArcGIS 10.3 for Server Map Cache Consumption Patch is the answer. After applying the patch, caches are now created using any tile management method and whether under load or not, cache directories are now renamed along with the service if a cached service is renamed, and service overwrites with a cache in place no longer leave behind a temp service. Thank you ESRI, I would consider this thread complete. David
... View more
04-27-2015
01:25 PM
|
0
|
4
|
3242
|
|
POST
|
Matt- I'd like to mark your reply as the correct reply to this long, long thread but unfortunately I didn't post this discussion as question. Nevertheless, the ArcGIS 10.2.2 for Server Map Cache Consumption Patch is the answer. After applying the patch, caches are now created using any tile management method and whether under load or not, cache directories are now renamed along with the service if a cached service is renamed, and service overwrites with a cache in place no longer leave behind a temp service. Same at 10.3. Thank you ESRI, I would consider this thread complete. David
... View more
04-27-2015
01:23 PM
|
0
|
0
|
2162
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 03-27-2026 01:27 PM | |
| 2 | 03-25-2026 06:29 AM | |
| 2 | 03-04-2026 11:14 AM | |
| 1 | 02-26-2026 09:46 AM | |
| 1 | 10-30-2025 11:25 AM |
| Online Status |
Offline
|
| Date Last Visited |
yesterday
|