It's a mix. If you consider a traditional map service, then (in dedicated instances), publishing a service will create an ArcSOC.exe and start consuming memory. If you start using it and max instances are higher than 1 then it may create more ArcSOC.exe's, and this starts to consume an increasing but linear amount of memory. The CPU loading is dependent on how often it's called. The memory usage relates to the fact that it needs to 'make an image' from the data. The internal workflow will be something like:
- receive web request
- determine layers, extents, filters, etc...
- request data from the 'geodatabase'
- receive data
- burn layers to a PNG/JPEG image
- respond to web request by streaming image
Clearly, this is a gross simplification. In a hosted feature service, the burn layers step is replaced by 'format data' (JSON/PBF). The manipulation of the text (data) is a much lighter weight computational operation. Importantly it doesn't need a SOC for every service instance. In effect a server that is only used for hosting services needs much less memory than a traditional ArcGIS Server.
In terms of which is doing most, then the Data Store will be doing the data heavy lift, with the Hosting Server doing the conversion to JSON/PBF. Obviously, if a little bit of data is requested then neither has a high workload, but as larger amounts of data re requested then both start to ramp up.
I think it would be fair to say that both are working in tandem. The data stores workload would be somewhat comparable to an Enterprise Geodatabase, but a specific hosting server will need less resources than a traditional ArcGIS Server. Many of my smaller clients run Enterprise Portal, Hosting Server, and Data Store (the Base Deployment) on a single machine, and then traditional server roles on individual machines as required.
Sorry, that probably hasn't answered your question, but hopefully paints a picture to increase understanding?
Scott Tansley
https://www.linkedin.com/in/scotttansley/
