Segregating Tuxedo services per server (performance considerations)

Question

Using Tuxedo 11.1 on Solaris....

Question is about performance/admin considerations when segregating services per server. We have a development gig that is looking to shave about 250 services down to 11 situations offered as 11 services. The idea is that there is an abundance of duplicate services that roughly return the same customer info and it would be logically better to package this overflow of "customization" (done mainly to meets specific needs of an subscriber) into a number of customer situations (like "give me everything about contact information", or "everything about relationships to other people"). These service situations will likely deliver more data and funnel obviously more calls into a single bottleneck (that has to be scaled horizontally). For example, we have services like "retrieve a customer identification" that get called 20 times a second (average 20ms) across 3 domains (against the same database). Getting the "identification" of somebody can have like 20 different flavors despite the return being somewhat polymorphic (maybe an extra property here and there but the base info is the same).

What I am wondering is the best way to package these 11 situations/services? Put them all info a single Tuxedo server then clopt out instances with specific services (likely just a single service). Or one service per server for readability? If I pile everything in to a single server what is the memory hit when clopting? Do only the services being clopted get put in memory or everything defined to the server? Not likely a serious issue for us (given the size of our park) but curious.

A rough ballpark (without detail knowledge of exactly how development is implementing) is that a service might potentially have to deal with 20 c/s * 20 (different flavors today) * 3 (domains) = 1200 calls per second. ;-)

Answer 1

Or one service per server for readability? If I pile everything in to a single server what is the memory hit when clopting?

GACK! don't do that!

The whole point of using TUXEDO is for scalability, the key to scalability with TUXEDO is carefully deciding what your services will be, regardless of readability, or programmer convenience. I've been through 10 or 12 TUXEDO design sessions with various customers and the TUXEDO professional services organization, several were with Marc Carges, the guy that wrote the first line of TUXEDO code.

In almost every case, the customer's would at some point question the way the services were being defined. The objections were usually along the lines of 'that will make the client application more difficult to code', or 'that seems extreme'. The ultimate answer was always the same, Marc Carges had the response down pat, he clearly was very used to these objections, and would reply something like this:

Scalability is hard, I know how to do it, and this is how.

The #1 factor in deciding what your services will be is to think about the database connection that service will utilize. The perfect TUXEDO service would open one table in the database, and that table would have one index. The fewer database resources a service hits the better. It's not possible to actually end up with 100% pure perfect TUXEDO services, so you start compromising, always keeping in mind that the point is to minimize the database resources required by any one service.

Don't worry about TUXEDO itself, it's the database that prevents scalability, TUXEDO's role to to get the database to scale. TUXEDO is extremely lightweight and is highly scalable itself, so don't worry about the impact of ANY design decision on TUXEDO itself, ALWAYS consider the effect of the design decision on the database engine.