Short Session Timeout and Session Timeout in Excel Services - Part 1

When you configure your Excel Services installation, you will notice that one of the configurations options for Excel Services is a list of “Trusted Locations”. You can get more information on Trusted Locations on the Excel Blog.  In the configuration of each of the Trusted Locations, you will see two settings – one called “Session Timeout” and one called “Short Session Timeout”. There’s a short description that gives a rather good explanation on what these are used for, but I thought I would elaborate a bit on it.

Each workbook that’s opened on the server is opened within its own session. These sessions remember the state of the workbook – what cells you have changed, what pivots you drilled down on etc.  Because of that, a session takes some resources (memory, disk) from the server. Our main concern is to get rid of these sessions as soon as possible so that new requests coming into the server (and subsequently creating new sessions) will have enough memory and disk space. However, if we get rid of requests too quickly, we would end up making Excel Services unusable. Basically, each session is given a timeout when it’s created. That timeout can either be the “Session Timeout” setting or the “Short Session Timeout” setting (the first defaulting to 5 minutes and the second defaulting to 30 seconds in beta builds). When no calls are made on a specific session for the timeout duration, it will go away and free all the resources it has been taking up.

So how does Excel Services decides which timeout value to use you ask?

Any call made from the API will automatically be set to the “Session Timeout” period, no matter what. Calls made from EWA (Excel Web Access) will get the “Short Session Timeout” period assigned to it initially. However, the first operation which is not a simple a paging operation (i.e. any setting of values, any drill downs on pivots etc) will cause the session timeout period to be “upgraded” to the regular “Session Timeout” setting.

The reasoning is as follows:

It is easy for an API call to behave “correctly” and close a session when it’s done with it. This means that if a session is kept opened but no operation is being done on it for a long time, it stands to reason that the API is actually busy with something else and may need the session later on. This also means that if the time-out is too low, the session may be lost by the time the API comes back to it and will error out. For that reason, we automatically give API calls a long timeout – hoping that they are written correctly.

With the EWA, it’s harder to know when a session is no longer needed. It is hard (if not impossible with some popup blockers) to figure out when your browser closes down or when it navigates away from the page. That means that there’s a good chance that sessions that will be created from the EWA will actually linger for the full timeout period if we allow them. That said, one of the bigger scenarios for using the EWA is in dashboard scenarios where it is simply used to display information and does not need to actually do any operations. In those cases, there is no need for us to actually keep the session for a long time – we can get rid of it quickly – and since the user did not do any operations on it, they will not lose anything.  For these two reasons, we have the short session timeout setting which will be assigned to all EWA sessions until the time when the user actually makes a request to the server, at which stage; the session will be assigned with the regular Session Timeout setting.

“Why do I care?” I hear you asking.

That’s a good question. For the most part, you do not; however, there may be some cases where it would actually be interesting to muck around with these values. In the next post on this matter I will supply a table that will give you some idea as to when you may or may not want to change these values.