TUXEDO Advisor

If you are using TUXEDO you are probably asking yourself some of these questions:

• How can I boost my Tuxedo performance?
• How many instances of Tuxedo server do I need?
• I wrote a new Tuxedo service - do I need a new server or can I add it to an existing server? To which server can/should I add this service?
• My system is slow after I opened my system to web-service and ESB.  What do I need to do to support this new volume of requests?
• I don't want to add more power to my machines (memory/CPU) how can I better utilize my machine to support my Tuxedo environment?
• My system is overload because of a problem that I have currently in my environment but I can not stop anything. What can I do?

The TUXEDO advisor helps you to get the right answer to those questions.

1. It enables you to find the best server for service to be located according to its common profile.
2. It helps you to deter main the minimum & maximum number of instance to a Tuxedo server based on your environment load.
3. It will help you to monitor your Tuxedo applications: Queues, Servers, etc.
4. It helps you to take actions on the Tuxedo domain in order to solve problems on a live system ("first aid").

How does the advisor do that?

Services common profile

When developing a Tuxedo system, one of the more common mistakes is to group dissimilar services in to a single Tuxedo server. Dissimilar services are services that do not share a common profile in terms of their response times, frequency of being called or business function.

For example, consider a Tuxedo server which contains two services:

• Service A - Is a short running (< 0.1 second average response time) service that is used by the solution for performing an auditing function and hence it is called many times by the system during the course of a business operation.
• Service B - Is a long running (15~20 second average response time) report service that generates reports based on the audit data and then outputs the reports to a corporate printing system. Service B is called about once or twice a day, depending on the frequency of the checks being performed by the security department.

While logically these two services could belong in the same service, by grouping them together in this way you are introducing the possibility of performance issues. In the scenario presented above, because service A is a short running service and Service B is called infrequently, the Tuxedo administrators have decided to run only two instances of the service to cover the load requirements.

However during the day to day operation of the system the Tuxedo administrators have also noticed that the users are experiencing intermittent timeouts and slowdowns and have been unable to explain why.

Service A and Service B does not have common profile so bind them together in a full scale environment will cause performance slowdowns for all clients that calls Service A during the time that Service B is running.