Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > ASP General > ASP Sessions - site is timing out early!

Reply
Thread Tools

ASP Sessions - site is timing out early!

 
 
Nebulus
Guest
Posts: n/a
 
      05-07-2007
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!

 
Reply With Quote
 
 
 
 
Anthony Jones
Guest
Posts: n/a
 
      05-08-2007

"Nebulus" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
> 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?




 
Reply With Quote
 
 
 
 
Nebulus
Guest
Posts: n/a
 
      05-08-2007
On May 8, 2:57 am, "Anthony Jones" <(E-Mail Removed)> wrote:

> 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!

 
Reply With Quote
 
Anthony Jones
Guest
Posts: n/a
 
      05-08-2007

"Nebulus" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
> On May 8, 2:57 am, "Anthony Jones" <(E-Mail Removed)> wrote:
>
> > 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.
>


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.

>
> 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!
>




 
Reply With Quote
 
Nebulus
Guest
Posts: n/a
 
      05-08-2007
On May 8, 9:36 am, "Anthony Jones" <(E-Mail Removed)> wrote:
> "Nebulus" <(E-Mail Removed)> wrote in message
>
> news:(E-Mail Removed) ups.com...
>
> 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!

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Sessions timing out quickly despite very high timeout set in web.config Alex ASP .Net 7 08-24-2007 09:57 PM
Moving from ASP Sessions to Database Sessions Bookham Measures ASP General 19 08-23-2007 03:51 PM
ASP.Net site timing out =?Utf-8?B?dmJ3aWcoVU5TVUJTQ1JJQkUpQGhvdG1haWwuY29t?= ASP .Net 3 12-13-2004 05:04 PM
Timing (forms) authenticated sessions out. Paul ASP .Net Security 2 04-26-2004 01:43 PM
Re: Relationship between IIS Sessions and ASP.NET Sessions? Ken Cox [Microsoft MVP] ASP .Net 1 08-08-2003 03:22 PM



Advertisments