Skip to content

Workflow & Architecture

Jump to bottom
Mark edited this page Oct 6, 2019 · 3 revisions

Overview

JCoz currently has a 3-tier architecture: Client -> RMI Service -> Profiled Java Process.

Setting up JCoz

Before a process can be profiled, a developer should do the following:

  1. Spin up the Java process with the JCoz native agent library specified on the command line:
java -cp client-0.0.1.jar:. -agentpath:$(readlink -f liblagent.so) test.TestThreadSerial -s > TestThreadSerial.log &
  1. Spin up the RMI service that will facilitate communication between your JCoz client, and the to-be-profiled Java process running with the native agent:
java -cp client-0.0.1.jar:/usr/local/openjdk-8/lib/tools.jar jcoz.service.JCozService > JCozService.log &
  1. Start your client process:
#java -cp client-0.0.1.jar:. test.JCozServiceTest | tee JCozServiceTest.log
TBD

Profiling a process

Once all of the components of the JCoz system are up and running, we're ready to profile a program. For this example workflow, assume you're trying to profile a Java program called foo. Assume as well that you want to see how to increase throughput at line 20 in the file Transaction.java. Note that this is a typical use case of a causal profiler: we have some important location in our program where we want to improve throughput (e.g. at the end of a transaction handler in a database engine, just after the "send" portion of a web server, etc). At this point, we'll assume the client has just opened.

A typical profiling workflow would be as follows:

  1. First you have to tell the client where to find the RMI service. Provide a hostname or IP and a port (or just use the default localhost:2216), and connect. This will create an RMI connection to a service that will let you communicate with the Java process you're trying to profile. Note that this connection can be to either a local or a remote service.
  2. The service receives the client request and opens up an RMI connection. It will then use the Java Lang Virtual Machine class to get a list of the JVM processes running on its local host.
  3. The RMI service sends a list of available Java processes to be profiled back to the client.
  4. You then select a process to profile from the list sent to the client by the RMI service. In this case we want to profile foo, so select foo.
  5. The client sends the foo selection back to the RMI service, which attaches to the selected VirtualMachine process (foo) and creates an MBean Proxy connection to allow us to make JNI calls from the Java layer to the natively running JCoz agent. This is useful because it allows us to configure and communicate with the Java process we're trying to profile from the Java layer rather than natively. The RMI service then notifies the client that it's attached to the process.
  6. The client configures how it wants to profile the process (e.g. where it wants to set a throughput point, etc) and notifies the RMI service.
  7. The RMI service, using JNI calls, configures the selected Java process (e.g. sets the throughput point, etc).
  8. The client tells the RMI service to start profiling the selected process.
  9. The RMI service, over a JNI call, tells the Java process to start profiling.
  10. The Java process runs experiments indefinitely, and sends its experiment results up to the RMI service over JNI calls.
  11. The RMI process receives the experiments from the Java process and sends them to the client over the existing RMI connection.
  12. The client receives new experiment results over the RMI connection, and saves them. They are also continuously rendered so the user can view the results in real time.
  13. At any time the client can reconfigure the current profiler settings (e.g. change throughput point location, timeout thresholds, etc).
  14. The client eventually ends profiling or terminates the connection, which ends the profile section.

A slightly higher-level visualization of this workflow is outlined as such: JCoz Architecture Diagram

Common Confusions

The workflow can be a bit confusing because there are several moving parts, some of which happen in Java, and some of which happen natively. See our FAQs page to see if your question is answered. If it's not, feel free to open up an issue in GitHub with the question label so we can answer it and add it to the FAQs.

Clone this wiki locally