How to connect to SAS on demand server faster in a flask app

[sadovsd]

I have a flask app using saspy that I deployed and make api calls to from my website. My previous strategy was to initialize and end the SAS session within each route of the flask app. I recently tried making a global sas session, which cut down the api response time significantly. But I soon learned that this creates issues related to SAS session being shared across multiple requests, or from a lack of appropriate memory management in the web application.

What are some ways of bypassing the long time it takes to create a sas session each time an api call is made?

[tomweber-sas]

Yes, getting a session from ODA can take a while, so I understand wanting to address that for your app. Have you used threads in python before? You could create a pool of SAS processes to reuse, or just asynchronously start new ones to use one time, but have then pre-started up before processing a request. At the end of a given request, asynchronously start a new session, while ending the one you used and returning from that request, so the new session is being created before the next request. Pre-populating a pool of these connections to use as requests come in could eliminate the delay of starting one. Are you using threads to process more than one request to your app at a time, or is each request processed and completed before the next can start?

[sadovsd]

Hello,
I tried that out and it cut down my response times significantly. I do have some questions though.

If i have a bunch of sas sessions started, how soon do they expire? Also, is there a max for the number of workers I can use or sessions I can have open at the same time? I'll need to implement some further error handling to address these.

Here's my app, for reference:

app = Flask(__name__)

CORS(app)

# Initialize queue and pool
sas_sessions = queue.Queue()
executor = ThreadPoolExecutor(max_workers=10)

def initialize_sas_session():
    sas_session = saspy.SASsession()
    return sas_session

# Preload SAS sessions
for _ in range(10):  # assuming you want to preload 5 sessions
    sas_sessions.put(executor.submit(initialize_sas_session))

def process_macro_call(sas_session, macro):
    sas_session.submit(macro)
    available_series_df = sas_session.sasdata2dataframe(table='available_series', libref='work')
    dates_available = available_series_df.iloc[0]['begin_year'], available_series_df.iloc[0]['end_year'], available_series_df.iloc[0]['series_id'], available_series_df.iloc[0]['item_code']
    return dates_available

@app.route('/getAvailableSeries',methods=['POST','GET'])
def get_available_series():
    # get the request arguments
    args = request.args
    
    results = []

    # read the contents of the file to get the existing macro
    with open('macro1.txt', 'r') as f:
        macro_code = f.read()

    futures = []
    # make a macro call for each itemCode user sent in from frontend
    for arg in args.keys():
        item_code = args.get(arg, 'default_value')
        # create a macro call based on the user input
        macro_call = f"%get_available_series('{item_code}');"
        # concatenate the existing macro and macro_call
        macro = macro_code + '\n' + macro_call

        # Use one SAS session per arg
        future_session = sas_sessions.get()  # blocks until a session is available
        try:
            sas_session = future_session.result(timeout=60)  # waits for the session to be ready, with a timeout
            futures.append(executor.submit(process_macro_call, sas_session, macro))
        except Exception as e:
            # Handle exceptions, maybe put the session back in the queue if it's still good
            print(e)
        finally:
            # Make sure to put the session back into the queue for reuse
            sas_sessions.put(future_session)

    # Wait for all futures to complete
    results = [future.result() for future in futures]

    # sas_session._endsas()
    
    return jsonify(results)

[sadovsd]

Also, I noticed that the 'available_series_df = sas_session.sasdata2dataframe(table='available_series', libref='work')' takes the bulk of the time in the response - 3 seconds compared to the 1.6 of 'sas_session.submit(macro)'. Are there any further optimizations I could make?

[tomweber-sas]

That's great! I'm glad that worked easily. As far as 'how long can you use a server', you're connecting to a SAS 9 Workspace server, so there's only a timeout configured in metadata for 'Inactive Client Timeout' which isn't a max amount of time you can use it, but rather if you haven't used it in that long, it will shut down the server. So, as long as you use a server once w/in that limit, over and over, you ought to be able to use it indefinitely. And, as far as how many SASsessions can you have at once, SASPy has no restriction, but I don't know if ODA has anything that limits you to some number of concurrent sessions or not.

In regard to performance improvements, I'm not seeing much for this. It's just a submit of code and a data transfer for the resultant table. Data transfer (sd2df() or df2sd()) will take time based upon the size of the data. It's a multi step process to gather metadata about the input data then generate code to move the data from the server to the client (or other way for df2sd) then initiate that transfer, creating the output data on the other side. Running SAS code by itself in SAS is the quickest, as it's just running in SAS w/ no other back and forth.

So, the one thing you can do in that case, it make the data you're transferring be no more than what you need. I don't know what's in the table you're moving or how big it is, but if there's more to it than you're using on the python side, only transferring what you need could be a way to decrease the transfer time. That can be done on the SAS side when creating what you're pulling over. Or you can use dsopts= on the sd2df call to provide sub-setting, if that's easier. Again, not sure what's in the table or if there's only a subset you need on the python side, but that could be a place to make a tweak, if so.

Tom