Remoting dashlet

For diagnosing and tuning remote method invocations (RMI), AppMon uses dynamic bytecode instrumentation to capture performance metrics, including remoting metrics, across horizontal and vertical application layers. A central AppMon Server correlates the resulting measurements to PurePaths dashlet. The Remoting dashlet displays the collected measurements.

Remoting dashlet
Remoting dashlet

Metrics

This is a list of every remoting metric that can be collected by AppMon. Specific sensor implementations for individual remoting protocols may not gather the whole set of possible metrics. If a metric is not gathered by a specific Sensor implementation, a dash ( - ) displays in the column.

  • Error State: The first, unlabeled column displays an icon that indicates the error state of the underlying PurePath: OK, Failed Transaction, Error.
  • Platform: The second, unlabeled column displays an icon that indicates the software Platforms involved in the remote call: Java for a pure Java remote call, .NET for a pure .NET remote call, and Java/.NET for a heterogeneous call.
  • Protocol: The type of the remoting protocol used for the call. Supported protocols are JRMP, T3, IIOP, and .NET remoting.
  • Side: Indicates whether a client call (C) or a server-side execution (S) was detected. If both sides of the remote call were detected, the column shows C/S.
  • Type: Indicates whether client and server involved in the remote method call run within distinct virtual machines.
    • local: Client and server run on the same virtual machine
    • remote: Client and server run on distinct machines.
    • unknown: Cannot be detected because of missing instrumentation on either the client or server side.
  • Method: The name of the remotely called method.
  • Class: The name of the class that provided the remotely called method.
  • Count: The number of times the remote method was called.
  • Failed %: The percentage of failures that occurred when calling the remote method.
  • Inter Tier Time [ms] (Avg): The average network latency, in milliseconds, of all remote calls of the method. See the note below the list for details.
  • Inter Tier Time [ms] (Min): The minimum network latency, in milliseconds, of all remote calls of the method.
  • Inter Tier Time [ms] (Max): The maximum network latency, in milliseconds, of all remote calls of the method.
  • Inter Tier Time [ms] (Sum): The accumulated network latency, in milliseconds, of all remote calls of the method.
  • Total [ms] (Avg): The average time elapsed for calls of the remote method as perceived by the client. The client-side total time includes the proxy overhead, network latency, delegation overhead, actual response time of the method implementation, and on the server side the delegation overhead and the actual response time of the method implementation.
  • Total [ms] (Min): The minimum time elapsed for a call of the remote method as perceived by the client.
  • Total [ms] (Max): Maximum time elapsed for a call of the remote method as perceived by the client.
  • Total [ms] (Sum): The accumulated time elapsed for all calls of the remote method as perceived by the client.
  • Exec [ms] (Avg): The average time to execute calls of the remote method as perceived by the client.
  • Exec [ms] (Min): The minimum time to execute a call of the remote method as perceived by the client.
  • Exec [ms] (Max): The maximum time to execute a call of the remote method as perceived by the client.
  • Exec [ms] (Sum): The accumulated time to execute calls of the remote method as perceived by the client.
  • CPU Total [ms] (Avg): The average CPU time used for calls of the remote method as perceived by the client.
  • CPU Total [ms] (Min): The minimum CPU time used for a call of the remote method as perceived by the client.
  • CPU Total [ms] (Max): The maximum CPU time used for a call of the remote method as perceived by the client.
  • CPU Total [ms] (Sum): The accumulated CPU time used for all calls of the remote method as perceived by the client.
  • CPU Exec [ms] (Avg): The average CPU time used for calls of the remote method as perceived by the client, excluding time of nested method calls.
  • CPU Exec [ms] (Min): The minimum CPU time used for a call of the remote method as perceived by the client, excluding time of nested method calls.
  • CPU Exec [ms] (Max): The maximum CPU time used for a call of the remote method as perceived by the client, excluding time of nested method calls.
  • CPU Exec [ms] (Sum): The accumulated CPU time used for all calls of the remote method as perceived by the client, excluding time of nested method calls.
Note

The latency is calculated as the difference between the client-side response time (total time) and the server-side response time (total time). The client-side response time is typically measured at the proxy/stub invocation, before marshaling/serialization takes place. The server-side response time is typically measured at the implementation or shortly before, after marshalling/serialization takes place.

Therefore:

  • The whole communication over the network is included (both directions).
  • Serialization times are included.
  • XML serialization times are most probably included in the latency. Minor variations may occur between different platforms, technologies, stacks, and protocols.

Tuning guidelines

Follow these guidelines to tune performance based on the metrics previously described:

  • Fields: To reduce the number of objects serialized or to reduce the network traffic volume, use the transient keyword to omit serialization of fields that are not required on the remote location.
  • Transport classes: Replace classes by special transfer classes that carry less information.
  • Local modifications: If the number of remote method invocations is high, especially because of calls to getter and setter methods, rethink whether methods should be invoked on a remote object or whether this object should copied to the remote location, modified without network and serialization overhead, and sent back to the remote location.
  • Call merging: Another technique to reduce the number of remote method invocations is to merge multiple remote method invocations into a single invocation. For example, multiple setter invocations could be merged into a single method call with multiple arguments. This merging reduces the network round trips to round trip.
  • Custom serialization for CPU optimization: Use custom serialization to optimize for CPU usage (externalizable instead of serializable) to eliminate the overhead cost of Java reflection. Replacing UTF-8 encoded strings with char[] can reduce CPU cost for converting strings to the UTF-8 format, but it also doubles network traffic volume.
  • Custom serialization for size optimization: Use custom serialization to optimize network usage. Multiple arguments could be merged together into a single bytearray. For example, merge two 16-bit short integers into a single 32-bit integer.
  • Network optimization: You can achieve further optimization on the TCP/IP network layer, for example by modifying the TcpWindow size. However, network-level optimization is beyond the scope of this topic.