Tuxedo and PeopleSoft review

 

How Tuxedo and PeopleSoft work together

In Tuxedo all data is written to and read from a IPC message cue. Think of a message cue as a little boxes of that reside in memory.


Once a user request reaches the application server its first entry point is via the JSL (Jolt Station Listener). This is just a port running on the application server that hands of that user request to a JSH (Jolt Station Handler). Every JOLT listener has a handler associated with it. The JSH is the process that writes that PeopleSoft request for data to the IPC message cue so that PSAPPSRV can pick up that request and take it to the database via ODBC. Once that request has been picked by PSAPPSRV an taken to the database then once that data is returned to Tuxedo it then will write to the message queue that that JSH os reading messages from. The key for tuning is to size the message cue correctly as you want all data to be written in memory and not swapped to disk. You have to tune the inbound as well as you tune the outbound. You tune Tuxedo from the message cue level and up as this is the location where data transfer occurs.

Each JSH has a value stated called clients per handler. This is stated in the psappsrv.cfg file. This value is currently set to 40. This means that once JSH will do the work of 40 clients. A client in a web world means browser window. This value is to high as this can cause a lot of swapping at the OS LEVEL. This is caused by the fact 40 clients writing message sizes of 4-8K at a time can overload the message cue and therefore cause it to swap to disk.

The Tuxedo rule of thumb is that when a message cue is 75 percent full Tuxedo will do a disk transfer regardless. We want all data transfer to stay in memory and never swap to disk. The end result to a user is that they will sit at a panel processing a transaction. By lowering the number of clients per handler as well we are also ensuring that if the JSH is stuck trying to write to a message cue that is being swapped that there are only 10 clients waiting instead of 40. By further reducing clients per handler you can also ensure that that the JSH is not context switching on the OS trying to fulfill requests cause at 40 clients per handler you are over working the handler therefore increasing CSW. You can use PERFMON to measure context switching in the operating system during go live.

Once the JSH has dumped a message on the message cue the PSAPPSRV process will take that request to the database. The data that has been returned by the database will have to be placed in an IPC message cue in order for the JSH to pick it up. Remember always that Tuxedo reads and writes messages from an IPC message cue. The data coming back from the database in a SA shop most of the time bigger than 64K. So you are also ensuring yourself swapping on the return trip back from the database.

Each server in PeopleSoft writes to there own individual IPC message cue.

Gautam Patel

http://pstuners.com