[ You are here:
XTF ->
Tips and Tricks -> Optimizing Performance ]
Optimizing Performance
When speed issues arise, it can be challenging to track down what parts of an XTF system are causing the slowness. This section discusses a few tips for optimizing the performance of XTF.
Optimizing Stylesheets
It's unfortunately quite easy to write a stylesheet in XSLT that will run
very slowly. XSLT is a very powerful language and attempts to isolate programmers from the details of how the XML document is stored and processed in memory. But reality eventually catches up with us.
One important practice is to avoid using XPath expressions that traverse every element in the entire document. In particular, avoid expressions like these:
- //*[SomeComplicatedExpression]
- descendant::...
- descendant-or-self::...
- preceding::...
- following::...
Instead, try replacing them with these much more efficient forms:
- //SimpleName/...
- key(KeyName, Value)...
- child::...
- ancestor::...
- ancestor-or-self::...
- preceding-sibling::...
- following-sibling::...
These techniques will fix most stylesheet performance problems. However, if you're still unclear where a stylesheet is spending its time, XTF provides a profiling tool that will help. In the configuration file for the servlet you're using, turn on stylesheet profiling like this:
<stylesheetProfiling profile="yes">
Then run your request through, and profile information will appear in the servlet container's log file. At the top it'll tell you the file and line number of the most time-consuming part of your stylesheets. Unfortunately (due to Saxon's aggressive optimization) the line number is only a hint; you'll have to look nearby to find the actual source of the problem. Try commenting things out near that point and see if you can narrow down the problem.
Note: Remember to turn off profiling when you're done, as it does slow down XTF processing.
Tweaking Java Memory Settings
If your system starts out fast and gets slower over time, or if you experience long pauses at fairly random intervals, chances are your Java Virtual Machine is running low on memory. To make sure, turn on the handy garbage collection option by passing the following to your Java VM (this is usually done through the servlet container startup script or configuration file):
-Xloggc:LogFileLocation
The method of passing this varies between servlet containers. For Tomcat you set the
JAVA_OPTS environment variable. For Resin you modify the
resin.sh script. In either case, you have to restart the servlet container for the change to take effect. Verify that messages are appearing in the log file you specified.
XTF has been developed to minimize its memory use, but some activities simply require lots of memory to work efficiently. Rather than worry, it's best just to give XTF the memory it needs, but if you're curious what kinds of activities need RAM, here are the main ones:
- Sorting large query sets (sort by title, author, etc.)
- Faceting with many groups or documents
- Large number of documents (i.e. millions)
- Handling many simultaneous requests, especially long-running ones
- Spelling correction
- Dynamic FRBR (experimental)
Now examine the log file. If you see lots of "Full" garbage collection events that are taking a long time, that's a signal that you need to increase the amount of memory avaiable. To do this, pass it a
-Xmx flag. The following example allocates 2048 megabytes (2 gigabytes) for the Java VM:
-Xmx2048m
Of course, you need to be sure that your machine has enough
physical RAM to accommodate your increased virtual memory limit. RAM is cheap and your time isn't, so upgrade the machine if necessary.
You may be tempted to play with the other Java virtual memory and garbage collection parameters; however, these generally have very little positive impact and may even degrade your performance. It's best to stick to adjusting the maximum memory, and let the excellent memory system provided by Sun handle the rest.