Hi Sarunas, While your approach addresses some of the concerns that I mention, it creates a number of others. With your approach, you should be aware of the following risks and complications. Their severity depends on your real-time SLA requirements (maximum permissible delay for a single query processing) and workload (maximum number of requests per second). Resource consumption overhead. Starting a new SAS process is a relatively heavy operation, especially if you will be connecting to any database within the script (and likely you'll want to - at least for logging purposes). Staying within SAS Base ecosystem, it will be too hard for you to implement the "thread pool" approach with sessions reuse. Both CPU and IO resources will get under pressure. SAS does lots of logical IO operations while a session starts up (loading binaries, accessing config files, etc). Normally these operations are cached by OS and don't reach actual storage, but under high load, you never know how one or another OS behaves and when and why it can get stuck. Especially since you are running Windows. Processing delay (you will waste precious milliseconds spawning SAS sessions) which may be not small, and also not always predictable. Have you seen (unhealthy) environments where starting up new SAS session sometimes takes 1 second, 5 seconds, 15 seconds for reasons unknown (most often some IO shortage or inefficiency of a sort)? I have seen it quite a lot. Lack of rate control. How do you see yourself implementing rate control? If too many requests came your way through the MQ, naturally you want to limit how many requests are processed in RTDM at the same time. You may want to only allow up to X concurrent requests processing (depending on your runtime environment sizing), while leaving others to stay in the queue until some current requests finish and free up the slot. With SAS Scripts, especially under Windows, it is not that straightforward to implement such logic. Maximum throughput. Your "unlimited loop" master SAS service that listens to the queue and spawns MP/Connect workers is likely to become a bottleneck, as it is single-threaded. Though I never tested it explicitly, I can imagine how it can process maybe 10 requests per second (even this needs testing), but can't imagine it processing 100 per second - this will be only 10ms per request. Other concerns from my previous message are still valid including High Availability (you may not have sufficient SAS licenses to run SAS Base scripts on two machines), logging clutter etc. I stand with my original point that while SAS scripts allow you to implement this integration (in principle), this is not an advisable solution to support any production workload short of extremely minimalistic. Best regards, Dmitriy.
... View more