We have an existing three cluster (three server) site being run through a single web adapter that handles all of our web, mobile, image and geoprocessing services. Based on our experience in a test environment we found that adding GeoEvent to an existing ArcGIS for Server box caused performance issues so we had a new production server built to host it. My question to this group is do you need web adapter on an ArcGIS server site setup focused on GeoEvent Processor? How are other groups adding GeoEvent processor into their existing architectures? I haven't been able to find recommendations specific to this extension.
Thanks,
Heather
Hi Heather,
Just some simple statements on the multiple items you mention:
No, you do not need the Web Adaptor on your ArcGIS Server machine hosting GeoEvent. You can choose to install it for all the reasons we recommend (http://server.arcgis.com/en/server/latest/install/windows/about-the-arcgis-web-adaptor.htm#GUID-030D...) but GeoEvent does not need it, nor do you need it to use GeoEvent. The Web Adaptor does not support any web socket-based GeoEvent outputs, including Stream Services. To set up a real-time server in a reverse-proxy manner while using any web socket based outputs, we recommend using NGINX (pronounced "engine ex") as it has good support for the web socket protocol.
You've done what we recommend for real-time deployments, which is to stand up a dedicated ArcGIS Server box with GeoEvent.
GeoEvent clustering has not worked out like we hoped and we no longer recommend using it. If you have a throughput rate greater than what can be handled by a single real-time server, it is certainly possible to set up multiple real-time servers to handle throughput, but you need to really think about things like how to split up your incoming messages, how to handle any stateful scenarios like 'enter' or 'exit' geofence operations or monitoring ongoing incidents, and how to handle event outputs appropriately (i.e. can you afford outputting messages in a non-chronological order? ...not necessarily an issue if they're time-stamped).
If any of this is confusing or you want more info, feel free to email me at mbramer@esri.com.
Mark