Profiling concepts

Profiling is a form of dynamic code analysis. You capture characteristics ofthe applicationas it runs, and then you use this information to identifyhow to make your application faster and more efficient.

Historically, profiling was performed only during application development. Thisapproach relied on the ability to develop load tests and benchmarks thatcould accurately predict a production environment.

Continuous profiling refers to profiling the application while it executesin a production environment. This approach alleviates the need to developaccurate predictive load tests and benchmarks for the production environment.Research on continuous profiling has shown it is accurate andcost effective^*.

Cloud Profiler is a continuous profiling tool that is designed forapplications running on Google Cloud:

• It's a statistical, or sampling, profiler that has lowoverhead and is suitable for production environments.

• It supports common languages and collects multiple profile types.SeeTypes of profiling availablefor an overview.

Configuring a Google Cloud application to generate profile datais a simple, one time process: link or run your service with a profilingagent included. After your application is deployed, theprofiling agent runs periodically to gather performance data and thensends that data to your Google Cloud project. For details about this process,seeProfile collection.

After you have collected profile data for your application, you can analyzethe data by using the Profiler interface.Analyzing profile data is typically an iterative process that relies on yourknowledge of the application design and its programming language.

^*See the followingGoogle-Wide Profiling: A Continuous Profiling Infrastructure for Data Centers andContinuous Profiling: Where Have All the Cycles Gone?.

Types of profiling available

The following table summarizes the supported profile types:

The remainder of this section provides more detail about each of theseprofile types.

Time measurements

• CPU time is the time the CPU spends executing a block of code.

  The CPU time for a function tells you how long the CPU was busy executinginstructions. It doesn't include the time the CPUwas waiting or processing instructions for something else.

• Wall-clock time (also calledwall time) is the time it takes to run a block of code.

  The wall-clock time for a function measures the time elapsed between entering and exiting a function. Wall-clock time includes all wait time, including that for locks and thread synchronization. The wall time for a block of code can never be less than the CPU time.

  Note: When the number of samples is low, the wall time can appear to be less than the CPU time in a sampling profile such as Cloud Profiler.

If the wall-clock time is longer than the CPU time, then thatindicates the code spends time waiting. When the difference issubstantial, your application might have a resource bottleneck.

If the CPU time is similar to the wall time, then that indicates thecode is CPU intensive; almost all the time it takes to run is spent by theCPU. Long-running CPU-intensive blocks of code might be candidates foroptimization.

Heap (memory) usage

• Heap usage (also calledheap) is the amount of memory allocatedin the program's heap at the instant the profile is collected. Unlikeother profile types where data is collected over an interval, thisprofile type collects the heap usage at a single point in time.

• Heap allocation (also calledallocated heap) is the total amountof memory that was allocated in the program's heap during the interval inwhich the profile was collected. This value includes any memory that wasallocated and has been freed and is no longer in use. As an example,consider a job that repeats the following sequence: allocates 1 MiB,waits 500 msec, frees 1 MiB, waits 500 msec. In the 10 seconds in whichthe allocated heap profile is collected, there are 10 allocations and10 frees. This profile would show 10 MiB allocated heap, as the frees aren'tconsidered. The average rateof allocation is 10 MiB/10 seconds or 1 MiB per second.

Profiling heap usage helps you find potential inefficiencies and memoryleaks in your programs. Profiling heap allocations helps you know whichallocations are causing the most work for the garbage collector.

Threading information

Applications that create threads can suffer from blocked threads and fromthread leaks:

• Blocked threads are threads that are created but are waiting for a lock.These threads are not currently running, and they might never run. However,a blocked thread might eventually run.
• Thread leaks occur when the number of created threads keeps increasing.

Blocked threads are one cause of leaked threads.

At the frame level, theThread profile displays the average number ofthreads that include that frame. This profile type collects thread usage at asingle point in time.

Contention

In a multi-threaded program, the time spent waiting to serialize accessto a shared resource can be significant. Understanding contention behaviorcan guide the design of the code and provide information for performancetuning.

Profile collection

The role of the profiler agent is to capture profile data from your applicationand to transmit this data to the Profiler backend using theProfiler API. Each profile is for a single instance of anapplication and it includes four fields that uniquely identify its deployment:

• Google Cloud project
• Application name
• Application zone
• Application version

When an agent is ready to capture a profile, it issues a ProfilerAPI command to the Profiler backend. The backend receives thisrequest and, in the simplest scenario, immediately replies to the agent. Thereply specifies the type of profile to capture. In response, the agent capturesthe profile and transmits it to the backend. Lastly, the Profilerbackend associates the profile with your Google Cloud project. You canthen view and analyze it by using the Profiler interface.

The actual handshake sequence is more complex than described in the previousparagraph. For example, when the Profiler receives a requestfrom an agent, the backend checks itsdatabase to determine if it has received previous requests from the agent.If not, the backend adds the agent information to its database. A new deploymentis created if the agent deployment fields don't match the settings of any otherrecorded agent.

Each minute, on average, and for each deployment and each profile type, thebackend selects an agent and instructs it to capture a profile.For example, if the agents for a deployment support Heap and Wall timeprofiling, on average, two profiles are captured each minute:

• For all profile types except heap usage and threads, asingle profile represents data collected for 10 seconds.

• Heap usage and thread profiles are collectedinstantaneously.

After the agent notifies the Profilerbackend that it's ready to capture data, the agent idles until the backendreplies with the type of profile to capture.If you have 10 instances of an application running in the same deployment, thenyou create 10 profiling agents. However, most of the time these agents are idle.Over a 10-minute period, you can expect 10 profiles;each agent receives one reply for each profile type, on average.There is some randomization involved, so the actual number might vary.

The Profiler backend uses Profiler API quotas andthe profile deployment fields to limit the profiles ingested.For information on viewing and managing your Profiler quotas,seeQuotas and limits.

Analyzing data

After Profiler has collected data, you can view and analyzethis data using the Profiler interface.

In the Google Cloud console, go to theProfiler page:

Go toProfiler

You can also find this page by using the search bar.