Fully featured low overhead profiler for Java EE and Java SE platforms.
Monitoring and profiling solution for Gradle, Maven, Ant, JUnit and TestNG.
Easy to use performance and memory profiler for .NET framework.

Profile remote applications

The following describes profiling of a .NET application running on a remote machine, i.e. when the application and the profiler UI run on different machines.

Read about profiling local standalone applications here.

Read about profiling ASP.NET on local machine here.

1. Enable profiling on the remote machine

Download the command line tool to the remote machine, unpack it to arbitrary directory and run the following command in command prompt started as administrator:

YourKitTools.exe enable

If you want to specify startup options, run:

YourKitTools.exe enable <comma-separated startup options>

You may need to restart Windows. For detail, please refer to the following MSDN article

Special notes on profiling a Windows service can be found here.

2. Start the application on the remote machine

Start the application you want to profile. It should start with the profiler agent.

To ensure it has started with the profiler, check whether the profiler agent log file has been created:
<user home>\.ynp\log\<session name>-<PID>.log

3. Connect to the application from your local machine

On the local machine, start the profiler and use "Connect to remote application" on the Welcome screen:

First, try to specify the remote machine host only, i.e. without port, as in most cases the port can be detected automatically. If automatic detection does not work or connection fails, please see Remote profiling troubleshooting

If you explicitly specified a port to be used by the profiler agent when launching the profiled application, you have to explicitly enter the port together with the host (using the syntax host:port). Automatic detection will not work in this case. Also, you should specify the pair host:port if there are so many profiled applications running simultaneously that for some of them there was no free port available in the predefined range.

SSH tunneling (advanced)

If you do not have a direct access to the host and port, you can use the built-in support for SSH tunneling.

To establish an SSH tunnel, use the following syntax:

user@ssh_server[:ssh_port] [host][:agent_port]

  • user and ssh_server are the credentials for the SSH connection to establish
  • ssh_port - specify if the server does not use the standard SSH port 22
  • host - the host on which the profiled application is running; ssh_server will create a tunnel to that host. If the profiled application runs directly on ssh_server, omit this parameter.
  • agent_port - profiler agent port. If not specified, all applications with agents listening on ports from the standard range will be discovered (the same as for a non-tunnelled connection).

Examples

  • john@server1 - connect to profiling application(s) running on host server1; SSH will connect as john
  • john@server1 :12345 - connect to the profiling application running on server1 with the profiler agent listening on a custom port 12345; SSH will connect as john.
  • john@server1 server2 - connect to profiling application(s) running on host server2, via SSH connection to server1 as john
  • john@server1 server2:12345 - connect to the profiling application running on server2 with the profiler agent listening on a custom port 12345, via SSH connection to server1 as john.

Authentication with a password or a private key is supported.

You will be asked to provide the password each time you connect. The password is not stored anywhere, and is securely erased from memory once the SSH connection is established.

Note: known hosts are not currently checked, and StrictHostKeyChecking SSH parameter is set to no.