Tuning the XML server

Contents

• Introduction
• Becoming aware of how your XML server normally performs
• Identifying causes of poor performance
• Tuning and configuration changes

Introduction

1. Be aware of, and familiar with, how your XML server performs under normal circumstances. Thus, you should be able to know what good versus poor performance looks like. To do this takes time. To obtain this performance awareness you need to review the available data on a regular basis.
2. When you identify poor performance you need to know where to look to identify the reason or cause.
3. Depending on the symptoms, etc. apply configuration or tuning changes, as appropriate.

Becoming aware of how your XML server normally performs

• Statistics in the Social Program Management XML Infrastructure Guide - outlines the information available in these files.
• Configuring the XML server in the XML Infrastructure Guide - identifies the configuration necessary to produce these files.

Identifying causes of poor performance

• Check the $CURAMSDEJ/xmlserver/tmp/xmlserver.log file for unexpected errors:
  • Look for any indications of socket timeouts or dropped connections, which could be indicators that the <THREAD_POOL_QUEUE_SIZE> setting is too small. As per the XML Infrastructure Guide, that setting determines the point at which requests are held inside the XML server rather than in the TCP backlog queue. How the TCP backlog queue behaves when it is exhausted depends on the underlying operating system and in some cases may retry or timeout the connection. Some indicators of socket connection issues in xmlserver.log might include:
    • WRN_CONN_SET_SO_TIMEOUT exceptions indicating socket reads are hitting the socket read timeout (XML server <SO_TIMEOUT> setting), which defaults to 60 seconds (60000 ms). However, there could be reasons for socket timeouts other than the TCP backlog queue being exhausted, for instance poor performance in the application server interacting with the XML server.
    • ITDXS521-IO ERROR messages occur when the XML server catches java.io.IOException exceptions and these could occur due to the <THREAD_POOL_QUEUE_SIZE> setting, described above.
  • Check the performance of the application server(s) communicating with this XML server to confirm it is performing adequately and not impacting the XML server.
  • Run Java garbage collection (GC) tracing to confirm and evaluate the performance of the Java Heap used by the XML server. Use the java.jvmargs Ant property to pass GC settings to the JVM when starting the XML server. For example, using an IBM JVM: ant -f xmlserver.xml -Djava.jvmargs="-verbose:gc -Xverbosegclog:/tmp/gc/verbosegc.log"
  • Confirm the overall system performance; for instance, CPU and memory utilization. There are a number of tools available for monitoring, depending on the context of the platform.

Tuning and configuration changes

• These XML server settings in xmlserverconfigconfig.xml, which are described in the related XML Infrastructure Guide, are specific to the XML server:
  • <THREAD_POOL_QUEUE_SIZE>
  • <THREAD_POOL_SIZE>
  • <USE_TEMPLATE_CACHE>
  • <SO_TIMEOUT>
• These Java JVM settings:
  • Thread stack size can be set when starting the XML server. For example: ant -f xmlserver.xml -Djava.thread.stack.size="-Xss8m". For more information see Overriding the Java thread stack size in the XML Infrastructure Guide. If you change the default number of XML server threads (<THREAD_POOL_SIZE>) this setting may also need to be adjusted.
  • Java heap is set in xmlserver.xml as an Ant property, java.maxmemory, specifying the maxmemory attribute of the Ant <java> task. For example: ant -f xmlserver.xml -Djava.maxmemory="1024m".
• For on premise deployments the XML server provides load balancing functionality, which is described in Load balancing and failover in the XML Infrastructure Guide. However, when deployed to Kubernetes the native scaling capabilities of that platform should be used instead.