How to improve performance of SOAP Services

Date: 10 January 2007
Product/Release: Visual LANSA 11.3
Abstract: SOAP request takes too long to process.
Submitted By: LANSA Technical Support

Description:

The processing time for a SOAP Service request seems to be relatively long. If you are finding that a SOAP request takes more than 20 seconds or so then there might be performance tuning issues. Obviously there may be many factors causing the slow performance, like a large I/O to a file or a performance intensive logic and the like. Note: RDMLX processing will be relatively longer then RDML processing.

However, listed below are few important points to check for when attempting to improve performance of requests.

Note: These steps are not restricted to SOAP processing only. It may be also be used when having general performance issues with LANSA Integrator.

Performance Tuning Considerations:

  1. Optimize (Optimise) the JAVA files to level 40. See online guide for more information on 'Optimize Java Service Manager (OPTJSM)'. The optimize operation has been seen to better the performance considerably.
     
  2. If not required, turn Integrator tracing OFF.
     
  3. Apply the latest CUME's and Java Group PTF's and Apache HTTP Server Group PTF's.
     
  4. Run the Apache instance in CGIConvMode BINARY/BINARY.
     
  5. Is there only one caller program calling the LANSA SOAP server? You could pre-start some CGI jobs.
     
  6. Is there high enough Activity Level for QBASE. The HTTP server and JSM by default will be running out of QBASE as well as other iSeries jobs. If the Activity Level is low only a small number of the jobs will be getting CPU time, you could be starving the jobs of CPU resources.
     
  7. To improve the TCP/IP connection time between the JSM_OPEN and the JSM server make sure that a DNS name is used as the host name on the JSM_OPEN optional argument or the value in the JSMCLTDTA dataarea. Also make sure that this DNS name is in the local HOST table.

    USE BUILTIN(JSM_OPEN) TO_GET(#JSMSTS #JSMMSG)
    Value
    Offset *...+....1....+....2
    0 'LOCALHOST:4560
    50 'JSM
     
  8. To improve data transfer rates between the DCXS882X service program ( BIF's ) and the JSM server, the send and receive buffers can be configured.

    The latest DCXS882X BIF will also set the socket options for send and receive buffers to 128K before the connect. TCP/IP will then negotiate the connection between client and server.

manager.properties – no tcp.buffer properties (use the TCP/IP default values):

# tcp.nodelay=*yes
# tcp.buffer.send=131072
# tcp.buffer.receive=131072

From trace file MANAGER.TXT

manager: tcp.port : 4560
manager: tcp.backlog : 20
manager: tcp.interface : *all
manager: tcp.nodelay : <null>
manager: tcp.buffer.send : <null>
manager: tcp.buffer.receive : <null>
manager: create manager server
manager: create socket address to listen on port 4560 across all interfaces
manager: bind to socket address
manager: start manager server
manager: server receive buffer size : 64000

Change TCP/IP Attributes (CHGTCPA)

Type choices, press Enter.

TCP keep alive . . . . . . . . . 120 1-40320, *SAME, *DFT
TCP urgent pointer . . . . . . . *BSD *SAME, *BSD, *RFC
TCP receive buffer size . . . . 64000 512-8388608, *SAME, *DFT
TCP send buffer size . . . . . . 64000 512-8388608, *SAME, *DFT

manager.properties – tcp.buffer properties:

tcp.nodelay=*yes
tcp.buffer.send=131072
tcp.buffer.receive=131072

From trace file MANAGER.TXT

manager: tcp.port : 4560
manager: tcp.backlog : 20
manager: tcp.interface : *all
manager: tcp.nodelay : *yes
manager: tcp.buffer.send : 131072
manager: tcp.buffer.receive : 131072
manager: create manager server
manager: create socket address to listen on port 4560 across all interfaces
manager: bind to socket address
manager: start manager server
manager: server receive buffer size : 131072

Note: Do not measure the response time on the first request. There is a big performance hit on the iSeries JAVA when loading classes for the first time.

Back to Top