Re: Slow listener connects on Windows NT

Hmmm...
The answer of Oracle Support looks like a typical Microsoft answer: the answer is correct but it doesn't help a damn. A few things to try:
1 make sure AUTOMATIC_IPC = OFF in the clients sqlnet.ora 2 in the same file make sure NAMES.DIRECTORY_PATH = (tnsnames, oname) Otherwise Oracle will try a few well known namesservers before switching to tns
If that still doesn't help, set TRACE_LEVEL_CLIENT = support in the same file
and watch the sqlnet trace file for any failed connection attempts before it starts using TCP/IP. Usually they are there. Then you might want to disable Oracle Trace.

Hth,

Sybrand Bakker, Oracle DBA

<dgh_consulting_at_my-deja.com> wrote in message news:7mv3bf$q31$1_at_nnrp1.deja.com...
> Hi! We have been doing some volume testing of a
> new client application, the back-end of which is
> Oracle 8.0.5 on Windows NT 4.0 (SP3). We are
> using Net8 and TCP/IP protocol. The clients are
> using SQL*Net Client v2.3.4.0.4 (might seem
> strange, but they use multiple Oracle-based
> applications, some of which are incompatible with
> Net8).
>
> I am using a test harness which spawns a number
> of plus33 (or plus80) sessions, each of which
> connects to the back-end database and executes a
> stored procedure which simulates the update
> activity which will be performed by the new app.
>
> My problem is that although the back-end server
> doesn't seem too troubled (disk queues, CPU and
> memory usage all within acceptable bounds), I
> can't get the listener to connect the SQL*Plus
> sessions at quicker than 1 per second.
>
> I believe that using the listener pre-spawned
> connections option is of little use in Windows
> NT, as these are not recreated after a user has
> disconnected (unlike in UNIX, for example).
>
> Oracle Support suggested setting
> USED_SHARED_SOCKET = TRUE in the registry to
> improve performance a little, but I note from an
> article in Metalink that this should NOT be used
> when running Oracle FailSafe (which we are
> using). Note that I have recreated the test in a
> non-clustered environment and still get the same
> result, so OFS isn't the problem.
>
> I have also tested with and without Oracle Names
> Server, and get the same result in both instances
> (appox. 1 connection per second). This is a
> worry, because if 100 users wanted to connect at
> once, the 100th would take over a minute and a
> half to connect. Although 100 connect requests at
> once might seem unlikely, in this case it would
> be possible because the app connects, does its
> stuff and then disconnects every time the user
> clicks a button. I am told that it was designed
> in this way for resilience!
>
> Help! I have logged the problem with both Oracle
> and Microsoft. Does anyone know which of these is
> to blame? I suspect that NT might not be able to
> handle the socket requests quickly enough. I
> tried getting into SMS Remote Control on the back-
> end server while a test was running, and had
> problems. I guess that this could back up my
> suspicion, but I'm still not sure. I have
> adjusted the listener QUEUESIZE, but this only
> affects the number of connect requests that are
> allowed to queue up - it has nothing to do with
> the speed of connections.
>
> Sorry this is such a bit post. I'd be VERY
> grateful for any help on the subject.
>
> Thanks v. much,
>
> Dave Henderson.
>
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
Received on Mon Jul 19 1999 - 08:03:16 CDT