|
POST
|
Hi Aaron- We have found that hyperthreading on the CPU must be disabled whether running SQL2008 or SQL2012 when using sql geometry, but not when using binary storage. We lost nearly half of our performance until disabled. We also found immediatly that spatial indices matter greatly with sql geometry, especially for complex polygon datasets like a parcels layer. The default grid levels(med x 4) and cells per object (16) did not perform well for us at all. After disabling hyperthreading, we set up our dbTune with index levels of (med, med, med, low) with 64 cells per object. We arrived at this level through trial and error as there still doesn't seem to be any effective guidelines- performance has been acceptable since. I had started a similar thread here, SQL Server 2012 and 2008: Geometry Performance - that asks if there are any performance gains when moving to 2012. SQL Server 2012 and 2008: Geometry Performancehttps://community.esri.com/message/96614#96614 It's been viewed just a scant 23 times with 0 replies, although this post appears to have done just that- Thanks David
... View more
08-21-2014
08:17 AM
|
7
|
0
|
5549
|
|
POST
|
Wow Jeff, you didn't have to do this, but thank you.
... View more
08-19-2014
12:37 PM
|
0
|
0
|
861
|
|
POST
|
Thanks for putting this up Jeff. Michael and I are trying to utilized the side panel popup to hold the results from a gp model that is returning fetures and graphics based on the linear distance from a selected feature, basically a select by attribute of an input layer then re-selecting user-input features base on a linear extent
... View more
08-19-2014
11:41 AM
|
0
|
2
|
861
|
|
POST
|
Thanks Matt- Oh sorry all I did mean RECREATE_ALL_TILES, not UPDATE_EXISTING_TILES in my earlier post
... View more
08-18-2014
09:17 AM
|
0
|
0
|
1802
|
|
POST
|
Good Afternoon all: I have a status update on this issue. On Friday, while working with Jon at ESRI Redlands, he was able to sucessfully re-create the behavior we have been experiencing regarding the bundle error move. In fact, Jon reported back to me that he saw the same behavior at 10.2.1 which I found quite interesting as we never experienced a bundle error move at 10.2.1, only cache failures for a given extent which could always be reparied. However, the good news is that this 10.2.2 bundle move error has now been logged as a NIM: [#NIM104348 In ArcGIS Server 10.2.2, you're unable to recache tiles while the existing tiles are being accessed. ] Which of course means the development team will now be looking at this issue. In the meantime, we all can go back to caching identical non-production services either on an edn or on a production GP cluster machine, as long as that service is not being accessed, and then moving the new bundles to production using REMDIR and XCOPY bat's. I have since last Thursday successfully completed three full UPDATE_EXISTING_TILES operations on a non-load basemap service of considerable cartographic complexity from scales of 577000k down to 1128K, both with and without the use of an AOI polygon. Thanks- David
... View more
08-18-2014
09:10 AM
|
5
|
2
|
1802
|
|
POST
|
Hi Nils- If you are using the attachment relate you have to keep in mind that the archiving doesn't traverse relationships on non-versioned data. I think you'll have to disable archiving, enable versioning and then re-enable archiving. -David
... View more
08-14-2014
03:12 PM
|
0
|
2
|
1446
|
|
POST
|
No, server needs the data-store. We have found that things are more stable if the connections are in a secure, shared environemnt. So, even at 10.0 we always did the same thing. What I think you're talking about is the option regarding data store connection same as publisher's connection (ie your desktop sde connection). I personally don't like to rely on my C:\Users\dcoley\AppData\Roaming\ESRI\Desktop10.2 sde connections for publishing, particularly if another publisher needs to access the mxd. So I get around that by always using the data-store connection from my desktop.
... View more
08-14-2014
02:52 PM
|
0
|
4
|
1969
|
|
POST
|
Yes I agree. I've had to do that a few times and re-configuring the web adaptor has always worked for us- David
... View more
08-14-2014
02:42 PM
|
0
|
0
|
1386
|
|
POST
|
Go ahead and place your sde connection files and fdgb's in the server-registered data-store default location, either on your server or shared directory. We use a subfolder in our data-store named DataConnections. Then we define other various folders under data-store containing mxd's to be published. Each of those mxd's is always sourced to a DataConnection connection via unc path. In this way, your published mxd's will always source your data-store connection and not various publisher's desktop connections
... View more
08-14-2014
02:15 PM
|
0
|
6
|
1969
|
|
POST
|
We've always gone in order: 10.1, 10.2, 10.2.1, 10.2.2. Cache bundles worked at every release unitl .2 I'm working with esri now on a ProcMon for further discovery . . .
... View more
08-13-2014
08:56 AM
|
0
|
0
|
1802
|
|
POST
|
Hi Michael, no. The bundle move error (which from what I see is really is a *.bundlex file not being moved from an arcgistemp folder on a gp machine in a cluster environment to a shared cahe directory) bundleissue is brand new at 10.2.2 (to us anyway). I've never encountered an bundlex move error prior to this release since the bundles have been in existence.....
... View more
08-13-2014
08:45 AM
|
0
|
2
|
1802
|
|
POST
|
Thanks Matt, interesing result regarding the Exploded v Compact. I too am working with Jon out of Redlands to get this solved. We ran some I/O tests yesterday using IOzone and thus far have determined that throughput does not seem to be the culprit. We will be running a ProcMon test later today and I will post the results
... View more
08-12-2014
12:08 PM
|
0
|
4
|
2464
|
|
POST
|
Here's what I do: Setup a PointToExtent Function that allows you pass a pointer tolerance in as a parameter base on map extent width in map coordintates thus:
Function pointToExtent (mapMain, point, toleranceInPixel) {
var pixelWidth = mapMain.extent.getWidth() / mapMain.width;
var toleranceInMapCoords = toleranceInPixel * pixelWidth;
return new Extent(point.x - toleranceInMapCoords,
point.y - toleranceInMapCoords,
point.x + toleranceInMapCoords,
point.y + toleranceInMapCoords,
mapMain.spatialReference);
}
then, in on-style wiring of your feature layers' query, pass the function to the geometry property of your query, along with a tolerance setting in pixels. Keep in mind that pixel tolereances change depending on resolution and scale, so you'll have to make some adjustments. Also, Jeff Pace employes a slightly different method that is not as resolution depenedent as what I'm showing here, so I would search his posts as well-
on(lyrName, 'click', function (event) { //mapMain
var query = new Query();
query.geometry = pointToExtent(mapMain, event.mapPoint, 10);
var deferred = lyrF.selectFeatures(query, //featurelayer
FeatureLayer.SELECTION_NEW);
mapMain.infoWindow.setFeatures([deferred]);
mapMain.infoWindow.show(event.mapPoint);
});
Here, '10' is my pixel tolerance in map coords, (meters) and seems to work pretty well for line features in WebMercator
... View more
08-11-2014
03:56 PM
|
1
|
0
|
2890
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | Wednesday | |
| 1 | 2 weeks ago | |
| 1 | 3 weeks ago | |
| 2 | a month ago | |
| 1 | 03-27-2026 01:27 PM |
| Online Status |
Offline
|
| Date Last Visited |
yesterday
|