Banner 8 Upgrade, Portal up or down?
We've noticed that when Banner is unavailable, our Portal becomes very slow and unresponsive. Is this true of everyone running Luminis 4.x?
For those of you that upgraded to Banner 8, did you leave your Luminis portal up or take it down as part of that process?
I've considered leaving it up, and trying to configure Luminis to remain fast. By either figuring out how to make Luminis think that we do not have Banner at all, or by reducing timeouts/threads, or other banner pool properties.
I'd be curious to know what other schools have done through a Ban 8 upgrade with respect to their portal.
Banner 8
We left Luminis up when we upgraded Banner and didn't notice any performance degradation. Do you have Luminis channels for banner deployed? During the banner upgrade you may want to disable those.
disable banner channels
I take it you don't have Banner channels deployed? Is that why you didn't see a performance hit?
I'm not sure how I would disable the channels. Physically move the channel car files to a temp dir maybe?
Banner channels
We actually do have these channels deployed but we are in the process of phasing them out. These have caused a lot of issues during high load usage periods. We typically have 4000+ users normally and much more (almost 2-3 times) during registration, 1st day of a semester, grades. These channels cause concurrency issues with the BANPROXY user in the Banner database and that eventually brings the banner database down in a matter of minutes.
During an upgrade, you can take these channels out from the layout and yes, you can move the car files to a temp directory.
odd then
Well, darn, I was hoping you'd say "We don't have the Banner channels". I'm scratching my head why our Luminis slows down so much then. We have 2,000 concurrent users, and none of the servers are hardly used. Within a minute if Banner going down, Luminis login speed crawls to a halt, and eventually the overall performance slows way down also.
Channels on Home Tab
By any chance, do you have any Banner channel on the Home tab (or the default tab that the user first sees after login)? Since you mentioned that the login process slows down after banner is taken down, that was my first suspicion.
I am assuming you are not using Banner Identity Management (which is a different beast) that can also have a similar effect.
no channels on home tab
We have no banner channels on the home tab. And are not using Banner Identity.
Sungard got back to me with this
--------------------------------------
Hi Jason,
My understanding from having read FAQ 1-3MKTDW is that setting the com.campus... property = true will allow for a more graceful recovery from a DB restart/disconnect. Furthermore, I do believe that the com.campus... property does take precedence over the pipeline.datasources... properties.
So I think what's happening in your situation is that a) the Banner DB goes down, b) the bannerPooled connections are becoming stale due to the fact that they are not being validated and c) those stale connections are in turn leading to the Luminis login performance degradation.
Now, I did do some additional research and found that there is another FAQ 1-3JN4WY (also attached) which states that setting the com.campus... property = true may lead to other performance implications, which I believe ties back to the notion that you bring up. However, I've learned that these other performance implications were resolved in the latest recommended hotfix for Luminis 4.1.1 (41). So assuming you're running 4.1.1.41 or higher, this shouldn't be a concern.
(update to be continued in next posting)
------------------------------------
I wonder, could you tell me what you have these configman values set to? Perhaps that is the difference.
com.campuspipeline.rdb.conn.ConnectionPool.getPooledConnection.validateconnection=false
pipeline.datasources.bannerPooled.validateconnections=true
pipeline.datasources.uPortalPooled.validateconnections=true
My settings
I have the same settings as you have:
false, true, true
pipeline.datasources.bannerP
pipeline.datasources.bannerPooled.connectionMaxWaitTime
Do you have that one set?
BannerPooled
No, we don't. But we have these two:
pipeline.datasources.bannerPooled.connectionMaxLockTime=30
pipeline.datasources.bannerPooled.connectionMaxUses=0
Tried something, didn't work.
We changed 4 configman values. connectionMaxWaitTime (10), validateconnection (true), inactiveTimeout (20), and connectionMaxLock (15).
And then took our production Banner offline by pulling the network cable. Our Luminis Portal slowed, and then eventually started timing out logins:(
We are going to try another test today, putting the Banner DB in restricted mode, and see if the Portal behaves better since it can at least see Banner.
I've been in talks with Sungard, and a couple outside consultants from sigcorp, and there doesn't seem to be any known reason why this is happening. My best guess right now is that since we were one of the first Lum 3 --> 4 migrations, that we have legacy Lum 3 configman values that are conflicting or causing trouble.
banner down, luminis slow, solved.
Every friday we take banner down for a full cold backup. Several of us stayed up late to watch the portal behavior, and during the cold backup of banner, the portal did not have any performance issues.
Now we suspect that since the banner server was ping-able and the listener was up, despite the DB being down, the portal behaved better. Our Banner 8 upgrade is going to require the DB to be in restricted mode for most of the time, so this friday we are going to do the backup in restricted mode, with the listener up, rather than a cold backup, and see if the portal stays fast.