RE: [U2] RedBack Garbage Collection

2007-06-15 Thread John Jenkins
John

I went stateless with stateless RBOs and OPEN2 rather than OPEN method.

We were using Object Handles in Session Variables to hold connection
handles. So once we lost those if we had stayed stateful then we would have
had to use the REFRESH method to restore the state of objects when each page
that needed them was invoked.

We chose not to run stateful because the way the website was getting hits
this would be a performance bottleneck downstream (and it did grow - A
LOT!). So we ran stateless RBOs with OPEN2 method and instantiated
connections on each invocation where needed. 

What did we need to keep? Well a fair amount of DATA - we put that in form
fields, hidden fields, browser cookies, query strings etc... it was
surprising how much we just didn't need. All the web pages were re-entrant
(display / enter / change - ONE form for each form use on the WWW - modified
by the method used to invoke it.).

In the end stateless - while (maybe) not as fast as stateful with object
handles let us achieve a few key things we needed:

1. Scalability
2. Able to use a web farm
3. Focused us on moving as much processing load from the backend to the web
pages. (lightened the backend so maybe in the end was faster).

It paid back big time for us (and the client) - and they have gone on to
greater and better (RedBack) things since then. They must be one of - if not
THE -  biggest RedBack users worldwide.

Regards

JayJay

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John Bullard
Sent: 13 June 2007 13:40
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] RedBack Garbage Collection

Thanks for the info; I had not heard this one before.  All of the apps
that I have written so far are quite small-scale and, although I do use
session variables, I don't think they are affected by the conditions
that you mentioned.

However, we all know what will happen if I make the ASSumption that they
will STAY small-scale; so I have to ask for my future work:

What methodology do you use in place of session variables?

John B.


-Original Message-
...
The problem is IIS itself: IIS Session Variables are thread-locked to
the
specific IIS thread on which they were instantiated.
...
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] RedBack Garbage Collection

2007-06-13 Thread John Bullard
Thanks for the info; I had not heard this one before.  All of the apps
that I have written so far are quite small-scale and, although I do use
session variables, I don't think they are affected by the conditions
that you mentioned.

However, we all know what will happen if I make the ASSumption that they
will STAY small-scale; so I have to ask for my future work:

What methodology do you use in place of session variables?

John B.


-Original Message-
...
The problem is IIS itself: IIS Session Variables are thread-locked to
the
specific IIS thread on which they were instantiated.
...
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] RedBack Garbage Collection

2007-06-12 Thread John Jenkins
The problem is IIS itself: IIS Session Variables are thread-locked to the
specific IIS thread on which they were instantiated.

For an example:

It is a quiet time of day, and 500 people access the IIS web server (running
ASP) and the ASP uses session objects. The session objects are stored on the
web server and are specific to the IIS thread on which they were
instantiated, and hence tie that browser (client) instance to that thread.  

Activity picks up - more load ... and as long as the Session variables are
still valid (scope / timeout and IS (not RedBack) Garbage Collection), those
original sessions (which are only runnable on the threads on which they were
instantiated) start queuing. There is spare capacity - it's just that those
Browser instances will only run on specific threads, and if those threads
are busy then you get queues.

If you destroy a Session variable - fine, but of course you would not need a
Session variable if you destroy it every time you exit an ASP page - it
would just be any other object handle.

Caution: IIS Garbage collection depends upon a number of tunables, and you
can run out of resources if you don't get everything set up right. It also
has a minimum delay inbuilt - I think this was about 20 minutes regardless.

The variables are:

ASP Queue Depth 
ASP Queue Timeout
Number of ASP Queues

The default settings varied with different IIS versions, with IIS 5 I
believe they were:

Queue Depth (don't remember)
Queue Timeout (none)
Number of ASP Queues 4

Change to suit - for openers I used 100/ 15 (secs) / 20

Hope this helps - Session Variables are the best idea I wish Microsoft had
never had (since I had to remove every one by recoding).

Regards

JayJay


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John Bullard
Sent: 11 June 2007 15:21
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] RedBack Garbage Collection

 * Don't use session variables in IIS


Could you expand on this statement?  Do you mean don't use them to store
a copy of the RBO or not to use them in general with RedBack?
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] RedBack Garbage Collection

2007-06-11 Thread John Bullard
 * Don't use session variables in IIS


Could you expand on this statement?  Do you mean don't use them to store
a copy of the RBO or not to use them in general with RedBack?
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] RedBack Garbage Collection

2007-06-02 Thread John Jenkins
For the older versions of RedBack that was a standing recommendation:

Set the GC purging criteria to something reasonable, but the interval sky
high to run never. Then run REDBACK.GC from a PHANTOM, crontab or Windows
scheduler (whichever suits).

Other standing advice:

1. Set WWSTATE to large (10's of K), static hashed, and a large block size
2. If upgrading to a version of RedBack that used WWSESSION to record and
purge WWSTATE then manually purge WWSTATE on your upgrade (WWSESSION is an
invert file index - and has no entries, so nothing left in there
historically will be purged). 
3. Positively set the Garbage Collection parameters - even if you don't need
to change them. One of the RedBack versions had invalid parameters on
installation and a positive change was needed to fix it.

Notes on stuff that people tend to forget:

* STARTBACKEND=1 for production use, 2 for developers
* Turn of the stats for marginally better performance in you don't need
stats.
* Don't use session variables in IIS


Regards

JayJay

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andy Pflueger
Sent: 30 May 2007 17:34
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] RedBack Garbage Collection

On 5/30/07, daverch [EMAIL PROTECTED] wrote:
 Just run REDBACK.GC from your account with RedBack installed on it or from
 RBDEFN account.


We run REDBACK.GC at the end of a nightly process we run as a phantom
and works very well. Just thought that little 2 cents worth of info.
;)

Andy
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] RedBack Garbage Collection

2007-05-30 Thread Anthony Youngman
I seem to remember a bug in garbage collection at some point. When did
it last run (time of day, not date!)?

There was something about it not working if the previous run was just
before midnight, because all time comparisons were earlier than the last
run so it couldn't calculate time since last run.

That might well not be the problem here, but hey, it's an idea to
investigate...

Cheers,
Wol

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: 30 May 2007 12:14
To: u2-users@listserver.u2ug.org
Subject: [U2] RedBack Garbage Collection

Hi

Does anyone know why garbage collection could stop working on RedBack
(4.2.3), or how I can bring it back to life? 

I have a client with state file that is badly undersized, with 160,000
sessions (and rising) in the LOADBAL.COUNTER. It is not (yet) configured
to use the WWSESSION file. It looks like collection hasn't happened
since February when there was a power failure.. despite RedBack being
restarted since.

Parameters in WWCONTROL GARBAGE.COLLECT are fine.

Thanks

Brian
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] RedBack Garbage Collection

2007-05-30 Thread brian
Wol

Bingo!

Brian

I seem to remember a bug in garbage collection at some point. When did
it last run (time of day, not date!)?

There was something about it not working if the previous run was just
before midnight, because all time comparisons were earlier than the last
run so it couldn't calculate time since last run.

That might well not be the problem here, but hey, it's an idea to
investigate...

Cheers,
Wol
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


RE: [U2] RedBack Garbage Collection

2007-05-30 Thread daverch
Just run REDBACK.GC from your account with RedBack installed on it or from
RBDEFN account.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, May 30, 2007 5:14 AM
To: u2-users@listserver.u2ug.org
Subject: [U2] RedBack Garbage Collection

Hi

Does anyone know why garbage collection could stop working on RedBack
(4.2.3), or how I can bring it back to life? 

I have a client with state file that is badly undersized, with 160,000
sessions (and rising) in the LOADBAL.COUNTER. It is not (yet) configured to
use the WWSESSION file. It looks like collection hasn't happened since
February when there was a power failure.. despite RedBack being restarted
since.

Parameters in WWCONTROL GARBAGE.COLLECT are fine.

Thanks

Brian
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/


Re: [U2] RedBack Garbage Collection

2007-05-30 Thread Andy Pflueger

On 5/30/07, daverch [EMAIL PROTECTED] wrote:

Just run REDBACK.GC from your account with RedBack installed on it or from
RBDEFN account.



We run REDBACK.GC at the end of a nightly process we run as a phantom
and works very well. Just thought that little 2 cents worth of info.
;)

Andy
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/