Best web publishing database

[KathleenWallis]

I need advice from anyone who has set up a successful workflow for publishing to webapp builder from a publish only environment. Here is my issue.

Our utility department wants to publish a webmap that has many layers and I am trying to establish the best publishing environment for the best map performance. The map I am publishing is for viewing only and will not be edited. 

1. I have successfully mastered publishing to ArcGIS online from my SDE server - however the data is in a database
          that is in state plane, not web Mercator.
2. I have successfully mastered publishing to ArcGIS online from a file geodatabase that sits on the C drive on my
          server.
3. Most layers are edited every couple of days, so a cached or tiled map is  out of the question. 

I have done all the scale dependencies and using only ArcGIS online or ESRI optimized symbol but want to take it
to the next step by

1. Setting up a database where all map layers are re- projected into web Mercator so that the web service does not have
      to re-project on the fly. This database will consist of only my published map layers instead of my entire LGIM
     database. 
2.  Have that geodatabase be a file geodatabase on my server's C drive so that I am not having to hit the SQL server
      the is continually being asked for queries by the daily editors.

So my questions are as follows.
1. Is it possible to synchronize these map service layers down from SDE to the file gdb on a weekly basis to that the data in the webmap reflects data that is not too stale. I am assuming setting up data replication will work?

2. Will the map service published from the file geodatabase reflect regular changes (updated attributes and additional
    points and lines, but not changes in schema) without my mapservice having to be refreshed or restarted.

3. Is there any other performance measure I can take that has not been mentioned?

Thanks in your patience in reading all this.   
 

Katy

[Anonymous User]

There seem to be two schools of thought... Folks from Esri Performance advised me to use a file gdb if the viewer is a read-only viewer, and store this file gdb on the web server. And in that case, I'd presume projecting to 3857 can only help performance. If the data frame is 3857 but the data is state plane it'll reproject on the fly and I presume incur a performance penalty. While maybe small, I'd rather just let the Replication also project the data weekly. I am about to make this our new workflow: replicate weekly from 10.51 SDE to FGDBs on another machine that's our web server and ArcGIS services server. I will say, services from our state plane SDE to viewers (hosted on a second machine) with heavy dynamic map services, are strained under load. The servers are very powerful. I am looking at all options to attack the bottlenecks. I will get Monitor installed, one of these days, once the system is deployed. I've aggressively set draw scales. I may look at webGL layers as well. They looked sweet in Dev Conf this year.  My main choice now now is:  SDE or FGDB. Thus far, I'm going FGDB; will come back at some point and weigh in on how it goes...

[KathleenWallis]

Kevin -

Thank you for your input. Please keep us posted as to how your results go.
Katy

[Anonymous User]

Sure thing Katy! I'm setting up a lot of SDE backend stuff still but will gather it to a comprehensive post after it's all done in a few weeks. One thing I've noticed already though, beware you set your datum transform before setting up a child replica to different coordinate system. For us, and perhaps with your group Katy, and many local govs, our SDE is in state plane. Which is appropriate, for our scale. For web viewers I want to convert to web mercator for speed. But be sure to set your data frame in that case to ITRF00 WGS84<>NAD83 conversion. If you don't, even if you go through the instructions in Create a replica in a different coordinate sys ... then at least for our area, I found it was NOT converting the datum and everything was off by 4 feet. When I selected this transform (as opposed to leaving at None, which it apparently defaults to) though, then it worked nicely. You set it in the properties of the Data Frame in the MXD containing the layers that you will then run this child replica workflow on. I imagine transforms matter even more in Cali with plate movement!