Re: measuring performance of scan listeners
Date: Mon, 7 Apr 2014 09:48:23 -0500
Message-ID: <CAFU3ey6JYLxgeerXCPE-1UvAYVA3ZhSonvUJGsT5pk9qaz1HiA_at_mail.gmail.com>
I haven't seen any replies to this, so I'll take a stab at it. And I'll admit up front, I think it is bizarre that SCAN would be suspected as a performance hit as opposed to having one listener per database. I'll keep the discussion to answering your question about monitoring listener performance, however.
Somewhere in here there needs to be a discussion about what is expected of listener performance. Maybe that is something you can take back to your customer. Is it number of connections established per minute? Is it number of bytes sent and received? There are many ways to frame it.
Beware also that it will be impossible to produce anything useful without testing both configurations. You'll have to set up scan listeners before you can run tests. That effort alone makes this somewhat moot, as I expect the performance (or suspected lack thereof) with SCAN will be immediately realized as soon as you spin up the scan listeners.
A quick and dirty method of monitor performance would be to grep the listener logs for number of instance name occurrences. Something like this: "grep <instance name> listener.log | wc -l". That will tell you how many times activity is logged for each instance. You'll want to further filter the listener log entries for your testing timeframe.
I'll admit I think that is a dumb way to test this, but maybe it is enough to prove the point. It depends on the audience, I guess.
For a real test, I think you would have to turn on listener tracing and
then use trcasst to generate performance stats. You would need to do this
both before and after setting up SCAN. It will be a lot of work. Looking at
the documentation for
11.2<http://docs.oracle.com/cd/E11882_01/network.112/e41945/trouble.htm#NETAG442>,
it appears that *trcasst -s* can give you lots of stats on bytes sent and
received, sessions served, and so on.
Andy
On Wed, Apr 2, 2014 at 11:51 AM, Dba DBA <oracledbaquestions_at_gmail.com>wrote:
> Clusterware(2 nodes): 11.2.0.4
> DB Homes: 10.2.0.4, 11.2.0.2, 11.2.4 (all use same clusterware)
> OS: Redhat 6.
>
> Migrating existing DBs from a customer to us. Our standard is to use SCAN
> listener. The customer uses 1 listener per DB. This is primarily because
> DBs upgraded from earlier versions. Its a much larger project to require
> TNS changes to many locations if you change to scan. In our case all tns
> needs to change because we are moving to different servers.
>
> Getting pushback about 'performance issues with just the scan listener'. I
> dont know how to measure this. Its outside the DB so the event system won't
> work. I don't think it matters since its the same set of CPUs, but Id
> rather get some numbers instead of guessing.
>
> We are also required to use SSL connections and plan to follow the
> following note. Not sure if this has any impact on performance.
>
> [image: Description: https://support.oracle.com/epmos/adf/images/t.gif]
>
> *Using Class of Secure Transport (COST) to Restrict Instance Registration
> in Oracle RAC (Doc ID 1340831.1)*
>
> Issues:
> 1. Some clusters have 20+ DBs. Concern(not my concern) is that scan
> listener alone can't handle this many DBs.
>
> 2. SSL connections: I think the customer actually set this up wrong. They
> had the TCPS configured in the listener, but gave their users the TCP
> connection. So they are not really using SSL. For security reasons, I made
> the decision to use SSL across the board and do it correctly. I dont know
> if this has any impact on performance and I dont know how to measure it.
>
> 3. Some DBs have very high process parameters (over 1100). This implies
> these DBs have applications that don't use connection pooling. So this
> would mean more listener usage. I dont know for sure. All I have to go on
> is the init.ora file. We are in the early stages. I also would be surprised
> if this matters to scan vs. lots of listeners.
>
> I dont think going to scan will impact performance. Its the same number of
> CPUs. I think lots of listeners may be a little worse since its more
> processes that need to be spawned. That being said, I have no idea how to
> measure this. Its outside the DB, so the DB event system won't work.
>
> Any suggestions on how to measure 'listener performance'. It sounds
> bizarre, but I don't know how to respond.
>
-- http://www.freelists.org/webpage/oracle-lReceived on Mon Apr 07 2014 - 16:48:23 CEST