End-to-end profiling of web applications / J2EE and client applications

Question

Is there a good tool for end-to-end profiling of a system that uses J2EE and has clients?

I understand that you can easily profile the server and client separately. However, I do not know of any tools that will provide you with information about the impact of the network connection between them and how this affects their performance. [The profiler will take into account from end to end when the application is stuck in communication and when it is being processed]

Answer 1

I am not aware of any profiling agent that provides ready-made functions for profile applications at the end. At least not at the time of writing this.

However, you can use DTrace to collect profiling information (not necessarily all the information provided by a typical profiler) from both client and server. An example of using this in a Java web application (with Firefox as a client and Tomcat as a server) is available in this article . The trick is that the JVM (running on the server) and the client have DTrace hardware built in, and in writing A DTrace script that writes collected information from traces to parsing output. Since the question is unclear whether the client is in Java, I will assume that the client is also in Java; if not, the application / executable must support DTrace hardware.

A few caveats should be noted:

• DTrace is not available on all operating systems.
  • It is currently available on Solaris 10 and Mac OS Leopard.
  • I don't know Dtrace support on Linux distributions, where SystemTap is the recommended alternative. FreeBSD has an experimental implementation of DTrace. It should be noted that SystemTap is not an implementation of DTrace for Linux, but a completely different entity in itself.
  • In MSFT Windows, you are on guard for yourself, at least for now.
• Assumptions about the JVM and client (since I know the server is running on the JVM)
  • If your client is a JVM, you must use a JVM that has a DTrace or equivalent (I mean SystemTap here), or your DTrace / SystemTap scripts will not work. This means that unless the authors of the JRE / JDK have added code to support DTrace / SystemTap for your distribution, you will not be allowed to use JVMs with such built-in support. If this is important in your context, OpenJDK 1.6.0 comes with tooling support for SystemTap, and Oracle / Sun Java 6 distributions for Solaris support DTrace. On Java 1.4 and 5 on Solaris, you need to install the JVMTI agent.
  • If your client is a web browser or a thick client written in another language, you must make sure that the process in which it is running can support DTrace. For example, DTrace with instrumental Firefox is available on Solaris 10 and, presumably, on Solaris Express 11 (I tested DTrace support only on OpenSolaris 2009.06). Firefox has not added SystemTap probes for a large number of Linux distributions, so you often need to create Firefox from the source code, with the appropriate flags in the Firefox build script to add probes; My previous experience in this process makes me believe that this is doable, but not easy. If you are using a different application as a client (neither Firefox nor JVM), you need to check the DTrace / SystemTap support for it.
• Writing good DTrace / SystemTap scripts to collect profiling information is not easy. You will need to learn a different language, and you will need to make sure that the scripts do not add their own overhead (and confirming Heisenberg's uncertainty principle in the context of profiling).

You can, of course, write DTrace / SystemTap scripts that work with remote clients and servers, but it is not recommended to write the collected control data to a socket (to avoid the above costs).

Answer 2

Starting with version 8.0, JProfiler has the ability to track RMI, web services, and remote EJB calls between two profiled JVMs.

In the JVM that makes the call, the call sites have hyperlinks that take you to the execution site in the remote JVM:

On the remote side, execution sites are recorded separately for each call site, so you can isolate the call.

Disclaimer: My company is developing JProfiler.