Re: MTS, Tuxedo, 1000 users, connections

In article <331DF5A7.2BD_at_mail.amsinc.com>,   steve_howell_at_mail.amsinc.com wrote:
>
> If I have a system with 1000 users hitting against an Oracle database
> on an HP box, what is my best bet for improving performance?
>
> -- use existing middleware, which has scheme to keep Oracle
> connections around in a cache (to share connections, essentially)
>
> -- use Tuxedo to manage connections
>
> -- have clients hit directly against Oracle, but use MTS to
> improve performance on Oracle
>
> I've heard rumors that keeping Oracle connections around to reuse later
> can backfire on you, because each connection has a large footprint in
> memory, and once you leave a connection idle for a while, when you go
> to revive the connection, Oracle has to do a lot of work to resurrect
> the connection anyway. So, you might as well just kill a connection
> when you're done with it, thereby freeing up memory, then get a new one
> when you need it.

A big piece of this depends on your response time requirements. You can a do a lot more with a TP Monitor than just manage connections. For example, you can queue up a complex transaction to a database so that the response is instantaneous to the user. You can go over to the server, do several SQL calls, and return to the client, sometimes in ways that you can't with PL/SQL, without multiple trips over the WAN/LAN.

You might also look at TOP END or one of the other TP Monitors if difficulty of development is a concern with Tuxedo.

TOP END has some tools like Active/X that make development easier. You can also develop servers in Visual Basic or Java with TOP END, so that the server code can use the same language as the client in cases where that makes sense (there are a number of considerations here.)

>
> If Tuxedo's the way to go, I'd like to know a little more about their
> underlying mechanism for taking workload off of Oracle, to make sure
> that they're not doing the same thing as our existing middleware.
>
> Is 1000 users really enough users to justify a TPM?

It depends. Number of concurrent users, etc., all affect the performance picture. There are, however, a lot of other reasons to build a 3-tier application besides number of concurrent connections.

For example, if you read the Gartner Group articles on "service-oriented" architectures, you'll find lots of examples where a 3-tier architecture easily allowed new front-ends (Web, VRU/CTI, Host systems, etc.) to tie into client-server environments that were 3-tier, but 2-tier fell on their face. Don't overlook merger & arcquisiton activity in your industry. Many a 2-tier system has fallen on its face after a sudden acquisiton grew the user base for a system.

My general recommendation is that if a system is large in either users AND/OR large in either developement dollars AND/OR strategic importance, strongly consider making it 3-tier (or N-tier). 2-tier can fall on its butt in adaptability as well as performance.

Feel free to contact me with any questions.

Alan Crowther
alanc_at_entersoft.com
908-575-9100

>
> I'm still learning about the business requirements of our application,
> but I imagine that users will generally be doing lots of intermittent,
> relatively small transactions.
>
> Thanks for your help.
>
> -------------
> Steve Howell
> (standard disclaimer)

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet