Optimizing SAS Event Stream Processing Studio Usage
In this post I will describe the use of stateful and stateless indexes in SAS Event Stream Processing model windows. I also illustrate the benefit of reading the warning messages from the generated project test log.
Here is an example of an online streaming project that was created using default settings. The project ingests data from pressure sensors in a simulated manufacturing process.
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
The train window is configured to use the kmeans streaming algorithm to segment the sensor readings into new clusters every 50 events, and the clustering results are computed in the score window.
Source Window Options
In the hierarchy of a SAS Event Stream Processing model, the source window is a crucial component. It's where the data enters the model. It can receive incoming events through connectors, which are configured in the source window itself, as well as through adapters, which run remotely to the project.
The properties of the source and other windows can be configured to optimize the performance of your model. Index type is one of the key properties that impacts performance. The index type determines how events are stored and processed, and indexes can be either stateful or stateless.
Stateful indexes are maintained according to the window's retention setting. The copy, join and aggregate windows use stateful indexes. Since stateful indexes store events in memory (or disk), they use more memory/disk than a stateless index, described next. They are ideal for smaller, ordered data and for huge data that cannot fit into memory, like tables with millions of rows. Pi_RBTREE and pi_HASH are stateful, in-memory index types. Pi_HLEVELDB and pi_HLEVELDB_NC use disk storage. Limitations of disk storage can lead to decreased performance with these index types.
Stateless indexes are not maintained. Events just pass through, and the index does not store events. Since events are not stored in memory (or disk) this leads to better performance. The pi_EMPTY index is the only stateless type. It is best for when we don't need to maintain any state because events are simply passing through the window with no updates or deletes.
Note: If a source window is followed by copy or aggregate windows that manage updates using a stateful index, you can make the source window stateless without any functional impact. Less memory will be required to run the SAS Event Stream Processing model, possibly improving the performance.
The source window is connected to derived windows through directed edges, forming a flowchart-like structure that defines the processing of streaming data.
The thunderbolt icon in the pressures window indicates the window is “stateful”. Event records are going to be accumulated in memory while the model is running. This can have adverse impact when the SAS Event Stream Processing model is deployed on an edge device with limited compute capabilities.
Interpreting Logs When Testing a SAS Event Stream Processing Project
Testing is an integral part of the SAS Event Stream Processing project lifecycle. When running a test, it's important to view the model's test logs. These logs provide valuable insights into the performance and functionality of the model. The logs can be filtered for specific messages, cleared, or exported for further analysis.
When interpreting the logs, look for any error messages or warnings that might indicate issues with the model. Also, pay attention to performance metrics, which can help identify any bottlenecks or inefficiencies in the model.
Here are some key performance metrics:
- Connector Current Rate: This metric shows the current rate of events per second for a specific connector.
- Connector State: This metric indicates the current state of a specific connector, which can be useful for identifying any issues with data input or output.
- Throttling Time: These metrics indicate the amount of time a window has been throttled. Throttling occurs when a window is temporarily blocked from processing events, often due to resource constraints. There are several related metrics, including the current throttling time for each window, the maximum throttling time across all windows, and the time when maximum throttling occurred.
- Project State: This metric indicates the current state of the project, which can be useful for tracking the overall status of your SAS Event Stream Processing project.
These metrics can be used to identify potential bottlenecks or inefficiencies in your SAS Event Stream Processing project. For example, a high throttling time might indicate that a window is being overloaded with events, which could slow down the overall processing speed.
The following warning messages indicate a potential problem with unbounded memory growth due to the stateful index in the Pressures source window.
When the source window is set to stateless, the icon and the warning log messages disappear.
The choice between stateful and stateless indexes depends on the specific requirements of your SAS Event Stream Processing project and the nature of the data you are processing. It's a balance between processing events efficiently and meeting the project requirements.
Best Practices for Creating Efficient Streaming Models
- Model Design: Start by designing your model at a high level. Identify the source windows, the derived windows, and how they're connected. This will give you a clear picture of the data flow and the processing steps in your model.
- Window Configuration: Each window in your model has properties that can be configured. Make sure to configure these properties appropriately to optimize the performance of your model.
- Model Testing: Always test your model before deploying it. Use the testing features in SAS Event Stream Processing Studio to run your model with test data and review the results. This can help you identify any issues or inefficiencies early on.
- Model Versioning: SAS Event Stream Processing Studio allows you to version your projects. This can be useful for tracking changes and for maintaining different versions of your model for different purposes.
- Model Deployment: Once your model is tested and ready, it can be deployed for real-time event stream processing. Remember that the model XML can be imported and exported, allowing for flexibility in deployment.
By following these best practices, you can create efficient and effective streaming models using SAS Event Stream Processing Studio. Thanks for reading and watch for stateful source windows!
Find more articles from SAS Global Enablement and Learning here.
