Digging more deeply we found out that actually we haven't been using MTS
at all (default/misconfiguration). Now we tried with MTS and performance
was greatly improved but the problem still persists. We will do some
experimenting with MTS and publish the results also here.
Michel Gauthier wrote:
>
> I'm not going to discuss Henry's problem exactly, but simply share our
> experience with MTS.
>
> We used MTS on a HP3000 with 7.2.3 for about haf a year. We used it because
> it made connections faster (and gave users illusion the app fast fast) and
> the SQL*Net PRESPAWN option was not available on our O/S. But after 5 or 6
> month, when we got bored enough of having "end of communication channel"
> errors, we switched back to a standard listener configuration. Connection
> became slower, but after that change, we stopped having problem with C/S
> application, and I have no doubdt it was because we left MTS.
>
> From what I read and heard, MTS had been developped by Oracle to suits
> applications where there are a very lot of simultaneous sessions that are
> very few active. Let's say 500 concurrent users which make 20
> trsanctions/hour (avg). In this kind of app, it would be very resource
> consuming that each user has its own server process (500 !). With MTS, you
> may configure about 30 dispatchers and 30 shared server process (rule of
> thumb) which is a lot less than 500.
>
> Since your app seems to be sometimes very loaded, I would guess it is really
> not the kind expected for a MTS configuration. With MTS, a client request
> could be served by server process #1, and its next request could be served
> by server process #24, you never know. During its whole life, a session
> could be served by many different processes on the host server: this means,
> in the communication perspective, a lot of context switch activity. Plus,
> with MTS, session information (called UGA I think) is stored in the SGA
> instead of the server process, which require configuring a slightly bigger
> SGA.
>
> So, I encourage you not just to change your MTS parms, but instead to stop
> using MTS (at least for a test). Communication problems are quite hard to
> troubleshoot, and MTS makes an intensive use of communication falicities.
> So, I wouldn't be surprised it solves your problem.
Received on Tue Dec 14 1999 - 02:36:29 CST
