ASP Sessions - site is timing out early!

[Nebulus]

We've got a website that's designed in classic ASP. While it's a good
product, the original design was badly done, and I've inherited a
monster.

At some point last week, users began calling in and complaining that
their sessions were timing out after minutes instead of the 120 minute
session timeout that's set in the global.asa

Now, at any given time, we have about 100 people logged into the site.
I did perform a check, and at any given time during a session, there
are 103 session variables per user - one.hundred.and.three.

Obviously, this needs to be trimmed down, and I'm working on reverting
a lot of those variables to page scope only, but we're working on a
plant to migrate the whole beast to dotNet in the near future. Right
now, we're trying to apply a band-aid solution.

Has anybody else had an issue with a site timing out like this?
Strangely enough, browsing the site with FireFox doesn't seem to
exhibit the early timeout solution. Unfortunately, we can't force all
the clients to use one browser and most use what's installed.

Any help would be appreciated. Thanks!

 

[Anthony Jones]

We've got a website that's designed in classic ASP. While it's a good
product, the original design was badly done, and I've inherited a
monster.

At some point last week, users began calling in and complaining that
their sessions were timing out after minutes instead of the 120 minute
session timeout that's set in the global.asa

Now, at any given time, we have about 100 people logged into the site.
I did perform a check, and at any given time during a session, there
are 103 session variables per user - one.hundred.and.three.

Obviously, this needs to be trimmed down, and I'm working on reverting
a lot of those variables to page scope only, but we're working on a
plant to migrate the whole beast to dotNet in the near future. Right
now, we're trying to apply a band-aid solution.

Has anybody else had an issue with a site timing out like this?
Strangely enough, browsing the site with FireFox doesn't seem to
exhibit the early timeout solution. Unfortunately, we can't force all
the clients to use one browser and most use what's installed.

Any help would be appreciated. Thanks!

Can you think of anything (even seemingly unrelated) that changed at 'some
point last week'?

Is the problem with some IE users or all IE users?
Does it happen all the time or some of the time?
Do you have active users using FF or was it a cursory test you made with FF?

If this problem really does vary with browser used then it's likely to be
cookie related, has there been a change in policy that has over tightened
IE's use of cookies?

More likely causes are:-

IIS6 application pool recycling while users are active. Check the recycling
properties of the application pool.

The application may simply being crashing for some reasons, IIS just spins
up another process so it may not be that obvious. Have you got anything new
happening in the event logs?

 

[Nebulus]

Can you think of anything (even seemingly unrelated) that changed at 'some
point last week'?

Is the problem with some IE users or all IE users?
Does it happen all the time or some of the time?
Do you have active users using FF or was it a cursory test you made with FF?

If this problem really does vary with browser used then it's likely to be
cookie related, has there been a change in policy that has over tightened
IE's use of cookies?

More likely causes are:-

IIS6 application pool recycling while users are active. Check the recycling
properties of the application pool.

The application may simply being crashing for some reasons, IIS just spins
up another process so it may not be that obvious. Have you got anything new
happening in the event logs?- Hide quoted text -

- Show quoted text -

Anthony,
Thanks for the tips on where to look. The site isn't using cookies,
although I'm not sure why basic login info isn't stored as a cookie.

As far as when the issue started, I can't say that we did any major or
even minor tweeks to the site - we've been working on some internal
apps.

I've got FF and IE loaded up for testing CSS and scripting, so it was
a natural progression to test the site on both browsers. We just
noticed that you can let FF sit for a while before timing out, and IE
will bump you now in the space of about 5 to 10 minutes.

I'll definitely check the App Pool to see what's going on and check
the event logs. Any suggestions as to what the settings for the App
Pool need to be for optimal performance?

In the meantime, I'm starting to carve out the session variables where
I can, but it's hard. There are a lot of junk and test pages left on
the site (dirty, filthy contract coders!) and a single session
variable shows up 57 times on 47 pages... sheesh!

 

[Anthony Jones]

Anthony,
Thanks for the tips on where to look. The site isn't using cookies,
although I'm not sure why basic login info isn't stored as a cookie.

ASP uses a cookie to hold the ID of the Session object. It's possible
therefore to configure a browser so tightly that is doesn't support even
these session level cookies and that breaks ASP apps that use the session
object.

That said it doesn't sound like that is the problem.

As far as when the issue started, I can't say that we did any major or
even minor tweeks to the site - we've been working on some internal
apps.

I've got FF and IE loaded up for testing CSS and scripting, so it was
a natural progression to test the site on both browsers. We just
noticed that you can let FF sit for a while before timing out, and IE
will bump you now in the space of about 5 to 10 minutes.

The idea that which browser you are using has an impact on how long the
session is held for has me baffled. I can't see how that would be
significant.

I'll definitely check the App Pool to see what's going on and check
the event logs. Any suggestions as to what the settings for the App
Pool need to be for optimal performance?

If there were a single answer to that question they'd be the defaults. The
true answer is 'it depends' but typically for in-house stuff you want only a
single recycle overnight.

 

[Nebulus]

If there were a single answer to that question they'd be the defaults. The
true answer is 'it depends' but typically for in-house stuff you want only a
single recycle overnight.

Thanks for the help - we've got somebody checking the App Pool to see
how well we can tweak it.

As a quick fix to the hemorraging, I added a little AJAX to the footer
include file that pings a singe page that returns the session ID. the
AJAX hits the "keep alive" page every 2 minutes, and we haven't had
any reported timeouts since implementing that code.

Yeah, it's a quick and dirty fix, but it works while we address the
real issues!