Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: OWS 2.1 on NT 4.0 problem

Re: OWS 2.1 on NT 4.0 problem

From: Gregory P. Lechkun <lechkung_at_tir.com>
Date: 1997/04/11
Message-ID: <334E6DDD.2336@tir.com>#1/1

Tim Ketchum wrote:
>
> I am running the OWS on a NT machine via SQL*Net to a host database. The
> problem I am experiencing is that over time I get many copies of the web
> request broker (WRBPROC.EXE) spawned until I eventually run out of
> memory. Which in turn causes all sorts of problems.
>
> One solution I've been offered is to switch the OWA back to work thru CGI,
> but that really is a dog performance-wise for the user.
>
> Any other ideas?
>
> -tim

Tim,
You should be able to adjust the listeners in two ways. The first way is the minimum number of listeners are up, these will automatically startup up when the server does. The second way is adjusting the maximum number of listeners that can brought up at anytime. When more connection are made to your OWS, more listener processes are brought up to handle the load. If this is not set to a reasonable level, you can run out of resources! Furthermore, when the connections to the OWS reduce in time, the number listeners will also reduce down towards the minimum number listeners (simular to the SQL*net listener processes on a DB server).

For our OWS (which is in development) we only allow two (only two developers right now). This gives us the performance we need without consuming resources. It would be a mistake do business through the CGI method, CGI will start up a process for each request and then exit so, your performance hit is the overhead of starting/stopping the CGI process (among other things).

The other thing is that maybe your OWS is heavily loaded. This may explain why too many listener processes are starting up and consuming all your resources. If this is your case, set the maximum listeners so that you handle most your load. This may cause your users delays in the handling of there request, and a worse case senerio is that it may look like your OWS is down. If that is the case, you better look into a large machine and/or another OWS to handle the overflow.

Take care,
lechkung_at_detroitedison.com
lechkung_at_tir.com
gpl :-) Received on Fri Apr 11 1997 - 00:00:00 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US