Re: I'm truly happy with this one, folks!

Keith Boulton doodled thusly:

>A postscript.

Not at all. Quite frankly, a main stream. And one I'd like to agree with almost all the way through!

>
>Most systems can be implemented using any technology from single tier
>mainframe to client-server gui and relational database to n-tier distributed
>architectures.

I like to put this one as:

"Of course we can develop it in Assembler and make it fly. Question is: do we have the time and budget to do so?"

>
>The problem is caused by failing to understand why a transaction monitor
>like tuxedo allows scalability. Firstly, it allows a connectionless

Sure. Tuxedo is not a new idea. It's a transaction monitor, like CICS was initially. And HVTIP from Sperry. And a few others. Nothing new. Overdue in the Unix environment, which never had anything like it. But as you point out, it ain't gonna make a project fly just by itself. Or the fact that it's the choice technology: the problem needs to be suited to a Tuxedo solution in the first place. And when the tuxedo solution is taken, then code must be written that doesn't violate the way transaction monitors are supposed to work.

>The situation actually seems to be getting worse with GUI design where
>systems mandate the use of a mouse, despite the fact that it takes many

Exactly. People forget that what the system is supposed to record is data, not mouse clicks or its movemement.

>Probably the best (ie most efficient) user interface I've ever seen was that
>for an airline reservation system where some incantation like string of
>maybe 20 characters was all it took to book 2 return tickets between 2
>airports, going out on one specific flight and returning on another.

Still around. Air Forces all over the world use a special, compact coding (message) to represent actions in a specific flight or command. Widely used and nowadays nearly standardized. Let's not forget that the airline industry was where transaction monitors were initially widely used. Air France and their TIP monitors back in the 60's spring to mind.

Another interesting one, related to this "do it as it is, not as it looks" subject.

The original insurance system in Oracle/Unix was written as a 3-tier C/S application. But the mob that wrote it subscribed to the school of hard knocks. So they did things like retrieve all the info from a policy when anyone asked for an adress of a subscriber. The principle was that most likely the user would want to view additional details of the policy, so the middle tier might as well be intelligent than reactive.

However, this brings an interesting point: given that the database server in such a system would be essentially delivering batches of data, that would classify it as a batch-oriented server, as opposed to an OLTP one. Ie, due to the "buffering" nature of the middle tier, the nature of the database server workload would be changed from OLTP to batch.

Which wouls suggest that larger block sizes and a batch-oriented tuning would produce better results.

What do you know: because the overall system was classified as OLTP, the database server was tuned as such. The usual: small(-ish) cache, 2K block sizes, small(-ish) redo logs, etc.

When we changed it to 8K block sizes, very large cache and very large redo logs, the performance jumped to nearly three times faster. But try and convince the "powers that be" that the database server had a batch workload instead of OLTP when the system was defined as OLTP? Might as well try to go up the proverbial without a paddle...

Result: the system stayed at 2K and more hardware was purchased to get the performance where it should be.

Amazing, isn't it? Still, better than what the new company's mainframers tried to do: run the system in a vanilla 3090 class box when it had just been struggling to run in a top-of-the-range Sequent NUMA-Q with umpteen CPU's, a few Gbs of main memory and oodles of EMC I/O.

Cheers
Nuno Souto
nsouto_at_optushome.com.au.nospam Received on Sat Feb 23 2002 - 16:39:31 CST