When planning for a deployment of ArcGIS GeoEvent Server in a typical ArcGIS Enterprise environment, there are a variety of concepts specific to GeoEvent Server to consider.
Event processing
When GeoEvent Server receives event data (or GeoEvents), five factors influence the time it takes for that event to be processed: size, rate, volume, analysis, and the output destination.
Event size
In most cases, no two events are the same. Events can have a varying number of fields and those with text fields can have an unknown number of character bytes. In general, the larger an event’s size, the longer it takes for that event to be processed by GeoEvent Server. In addition to the time it takes to process an event, larger events require more disk space to store their message queues versus smaller events.
Event velocity
The velocity of event data processed by GeoEvent Server is typically 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 rate at which events are ingested is an indicator of the load that can be expected on GeoEvent Server. Typically, the event rate is measured by the time between events with the same Track ID. The faster events arrive, the more demand GeoEvent Server will have on machine CPU and the local file storage system. As the denominator in the above equation, the shorter the event rate (smaller the number of events), the larger the event volume will be.
It is recommended that you reduce event velocity times for high-speed events since the rate of change is more frequent than that for lower speed events. In general, event velocity times must be smaller than the event rate. See the following example:
- Short rate event—Updates from an electrical substation may arrive every 1 second. A reasonable goal for processing this event would be significantly less than 1 second.
- Long rate event—Updates from a delivery service vehicle arrive every 60 seconds. It would stand to reason that a goal for processing this message would be on the order of 10-20 seconds.
Event volume
Event volume measures the number of unique events there may be within a system. The event volume is usually synonymous with the event set. Event volume is used in conjunction with event speed to determine the estimated event velocity. Typically, higher event volumes will lead to increased load on GeoEvent Server. Higher volumes may require better CPU and local storage performance than lower volumes. As the numerator in the above equation, the larger the event volume is the larger the event velocity. Examples of event volume include the following:
- Large event volume—A large transportation department tracking 15,000 state-owned vehicles.
- Small event volume—A local government tracking 12 snowplows.
Event analysis
As events pass through GeoEvent Server, the amount of processing and analysis performed on the events, using 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.
Event 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. Typically, uniqueness is based on an event’s 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 geofences. Geofences are loaded into GeoEvent Server and stored in memory. Because 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 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 machine RAM GeoEvent Server will consume to perform those real-time spatial relationships. See 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 states highly accurate 25 county polygon boundaries, each containing several thousand points