Tuning the XML server
- Becoming aware of how your XML server normally performs
- Identifying causes of poor performance
- Tuning and configuration changes
These are the basic high-level steps for tuning the XML server:
- 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.
- When you identify poor performance you need to know where to look to identify the reason or cause.
- Depending on the symptoms, etc. apply configuration or tuning changes, as appropriate.
Becoming aware of how your XML server normally performs
Your main source of XML server performance information comes from its stats/ThreadWorkerPool-* files. For more information see these XML server topics in IBM Documentation:
- Statistics - outlines the information available in these files.
- Configuration options - identifies the configuration necessary to produce these files.
Identifying causes of poor performance
If the the stats/ThreadWorkerPool-* files indicate a performance problem—for example: showing increasing processing times—these are some things to check:
- Check the
$CURAMSDEJ/xmlserver/tmp/xmlserver.logfile 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 IBM Documentation, 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 inxmlserver.logmight include:WRN_CONN_SET_SO_TIMEOUTexceptions 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 ERRORmessages occur when the XML server catchesjava.io.IOExceptionexceptions 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.jvmargsAnt 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; for instance, by using nmon.
- Look for any indications of socket timeouts or dropped connections, which could be indicators that the
Tuning and configuration changes
These are the areas available within, or closely related to, the XML server for tuning:
- These XML server settings in
xmlserverconfigconfig.xml, which are described in the related Configuration options topic IBM Documentation:<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". See the related Overriding the Java thread stack size topic in IBM Documentation for more information. - Java heap is set in
xmlserver.xmlas an Ant property,java.maxmemory, specifying themaxmemoryattribute of the Ant<java>task. For example:ant -f xmlserver.xml -Djava.maxmemory="1024m".
- Thread stack size can be set when starting the XML server. For example:
- XML server load balancing is described in the Load balancing and failover topic in IBM Documentation.