When planning for a deployment of ArcGIS GeoEvent Server in a typical ArcGIS Enterprise environment, it is important to consider certain factors specific to GeoEvent Server.
Event processing
When GeoEvent Server receives an event record, five factors influence the time it takes for that event to be processed: size, rate, volume, analysis, and the output destination.
Event size
An event record has a schema specified by a GeoEvent Definition. Event records can vary in the number of attributes values and geometry type (point, polyline, or polygon). String attributes may be a short name or contain many characters. Points contain a pair of coordinate values, while polyline and polygon contain a collection of coordinate value pairs. Larger event records (in bytes) require more system resources to process. GeoEvent Server uses both system memory and disk space, so larger event records need more memory and disk space.
Event velocity
The velocity of event data processed by GeoEvent Server is measured in events per second. Event velocity (events/second) is determined by the event volume (the number of events processed) divided by the event speed (how fast the events are processed).
Event Velocity (events/second) = Event Volume (events) / Event Speed (seconds)Event rate
The load on GeoEvent Server is proportional to the rate at which events are ingested, adapted, and processed. Larger volumes of event records and fast arrival rates cause GeoEvent Server to draw more system resources (RAM, CPU, and disk space) to ingest and adapt raw sensor data, process the event records it creates, and disseminate data from the processed event records.
It is recommended to minimize event record volume and velocity in analytics you configure while optimizing GeoEvent Server operations. For example, if data records from network sensors are expected to arrive every second, you must not configure complex real-time analytics which take hundreds of milliseconds to run on each event record. You must reduce the event record volume and velocity or simplify the filtering and processing that GeoEvent Server performs each second. If data records from a web service are expected to arrive every 30 seconds, the GeoEvent Server can use complex real-time analytics as long as the volume of event records received is completely processed before the next batch arrives.
Event volume
Event volume measures the number of unique events in a system. The event volume is usually synonymous with the event set. Event volume and the rate at which data is ingested from sensors determine event velocity. Higher event volumes increase the load on GeoEvent Server and require better CPU, RAM, and disk performance than lower volumes. The larger the event volume, the higher the event velocity. For example, a large transportation department tracking the position of 15,000 state-owned vehicles each minute represents a high event record volume and velocity. A township tracking the location of 12 snowplows every two minutes represents a low event record volume and velocity.
Event analysis
As events pass through GeoEvent Server, the amount of processing and analysis performed on the events, using configurable filters and processors, affects machine resources and event processing time. Complex processing and analysis workflows typically use more machine CPU as well as increase the amount of time to process event data. Certain analysis workflows such as using the field enricher processor to enrich an incoming data feed can increase utilization on the machine’s network connection.
Learn more about processorsEvent output destination
In many cases, the dissemination of event data does not affect GeoEvent Server. However, there are some considerations when working with certain outputs such as the event velocity may be higher than the capabilities of a specific output. When designing and implementing a performant GeoEvent Server, different approaches may be required if the expected event velocity is significantly higher than the output connector being used.
Event streams and sets
Event data is ingested into GeoEvent Server and is referred to as event streams or event sets.
Event streams
Event streams are defined as a set of events being ingested or disseminated by an input connector or output connector in GeoEvent Server.
Note:
An event stream is not the same as a stream service, which is a specific implementation of an output connector.
Event sets
While an event stream represents all the individual events flowing to or from GeoEvent Server, an event set represents the set of unique events in an event stream. Uniqueness is based on an event track ID. In most cases, the event set is synonymous with the event volume. Some examples of event sets include the following:
- In an event stream of vehicle locations, the event set encompasses all individual vehicle identifiers such as the vehicle VINs. The set of unique VINs represents the event set in this example.
- In a water level gauge event stream, the event set encompasses each unique water monitor identifier (for example, the serial number of the sensors). The set of unique water sensor identifiers is the event set.
Geofences
A key capability of GeoEvent Server is the real-time processing of event data against known geometries, or geofence geometry. Geofences are loaded into GeoEvent Server and stored in memory. Geofences are stored in memory; the amount of machine RAM is important and determines how many geofences can be stored in memory. In addition to the amount of RAM, the type of RAM can affect the speed at which geofences are accessed, especially when there are many geofences to be analyzed against.
More important than the number of geofences is the complexity of those geofences. The more points, or vertices, the geofences have, the more memory GeoEvent Server requires to perform those real-time spatial relationships. Refer to the following examples of geofences—each may contain an equal number of points and vertices and may consume the same amount of machine RAM:
- A set of 70,000 points representing points of interest across a region
- A region’s road network containing several hundred road centerline segments of a few hundred points each
- A state's highly accurate 25 county polygon boundaries, each containing several thousand points