Anzo Request Analysis

The Anzo Request Analysis mechanism records requests at the Combus/JMS level. Requests are logged in such a way that the conversation be automatically played back using a CommandLineInterface command. Responses are logged so that statistics and debugging information for each request is shown along with the request.

Configuring the Recorder

The recorder is configured inside the org.openanzo.combus.endpoint bundle. This is done by creating a properties file called personalConfig/org.openanzo.combus.Endpoint.properties in either of the server projects, depending which server is being run.

service.pid=org.openanzo.combus.Endpoint
org.openanzo.services.enabled=true
org.openanzo.combus.endpoint.recorder.enabled=true
org.openanzo.combus.endpoint.recorder.output=c:/tmp/combusRecorder.txt

The 3rd property enables the recorder, and the 4th specifies the output file. This file is open and closed for each logged request. Thus, it is possible to clear the contents of the file while the server is running, or even delete the file to start over.

Playing back a recording

The recording may be played back using the play command on the commmand line interface. It is recommended that you rename the file before playing it back since the recorder will likely overwrite it unless you disable the recorder or change output file. Here are a few examples

Basic playback:

anzo play -f combusRecorder2.txt

We can optionally playback requests for just a subset of Anzo services. The following example plays back only the request to the replication and query services:

anzo play -f combusRecorder2.txt -s rq

We can also filter for requests based on simple text matching on the body. For example, we can execute sparql queres with just the ?severity variable.:

anzo play -f combusRecorder2.txt -s q -b ?severity

Finally, we can filter using basic pattern matching on properties of the request. For example, we can execute a specific request by filtering on the message properties.

anzo play -f combusRecorder2.txt -r jmsCorrelationId=l1klbvosx9jl49dsm-18

More than one property match can be specified, comma-separated, and are linked with an OR relationship. In a future version we may supported more complicated expressions using AND and OR and <,> for properties.

The example above assume that all recorded requests were made using the CLI settings.trig user. However, some recordings might have multiple users. Since the record log does not specify passwords, you can specify a credentials file of the format

user1=password1
user2=password2

using

anzo play -f combusRecorder2.txt -c creds.txt

Additional Analysis Property

The record-playback mechanism is most useful for instrument various timing and performance characteristics of server-side code. Instrumentation is easy as long as the request's IOperationContext is in scope as it is in most built-in server components and user-defined ISemanticService implementations. Suppose we want to instrument cache hits and misses in the query service. We have:

if (RequestAnalysis.isAnalysisEnabled(context)) {
    RequestAnalysis.addAnalysisProperty(context, "cacheHit", Boolean.TRUE);
}

or

if (RequestAnalysis.isAnalysisEnabled(context)) {
    RequestAnalysis.addAnalysisProperty(context, "cacheHit", Boolean.FALSE);
}

All of these custom properties have a ans_ prefix in the log. For example:

...
@properties
operation=query
jmsCorrelationId=l1klbvosx9jl49dsm-18
ans_cacheHit=true
ans_operationTime=0
operationFailed=false
@body
...

We can of course filter on these properties as well. In these case, we want to replay only those requests that have caching information.

anzo play -f combusRecorder2.txt -r ans_cacheHit=true,ans_cacheHit=false

Processing request analysis data

Inspecting the recorded log is currently the only available method of analysis. Future plans are to export into formats that can be viewed in Excel or other tools, maybe even RDF.