AOP for performance monitoring in Spring Boot - Step-by-Step Execution

Concept Flow - AOP for performance monitoring

Method call intercepted

↓

Start timer

↓

Proceed with method execution

↓

Stop timer

↓

Calculate duration

↓

Log or record performance

↓

Return method result

This flow shows how AOP intercepts a method call to measure and log its execution time for performance monitoring.

Execution Sample

Spring Boot

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;

@Aspect
public class PerformanceAspect {
  @Around("execution(* com.example..*(..))")
  public Object monitor(ProceedingJoinPoint pjp) throws Throwable {
    long start = System.currentTimeMillis();
    Object result = pjp.proceed();
    long duration = System.currentTimeMillis() - start;
    System.out.println(pjp.getSignature() + " executed in " + duration + " ms");
    return result;
  }
}

This code intercepts method calls in com.example package, measures execution time, logs it, and returns the original result.

Execution Table

Step	Action	Evaluation	Result
1	Intercept method call	Method: exampleMethod()	Proceed to timing
2	Start timer	System.currentTimeMillis()	start = 1680000000000
3	Execute original method	exampleMethod() runs	Method returns 'Success'
4	Stop timer	System.currentTimeMillis()	end = 1680000000123
5	Calculate duration	end - start	duration = 123 ms
6	Log performance	Print signature and duration	Output: exampleMethod() executed in 123 ms
7	Return result	Return 'Success' to caller	Caller receives 'Success'

💡 Method execution completed and performance logged

Variable Tracker

Variable	Start	After Step 2	After Step 4	After Step 5	Final
start	null	1680000000000	1680000000000	1680000000000	1680000000000
end	null	null	1680000000123	1680000000123	1680000000123
duration	null	null	null	123	123
result	null	null	'Success'	'Success'	'Success'

Key Moments - 3 Insights

Why do we call pjp.proceed() inside the around advice?

Calling pjp.proceed() executes the original method. Without it, the method would not run, so no result or timing would be possible. See execution_table step 3.

Why do we measure time before and after pjp.proceed()?

Measuring before and after lets us calculate how long the method took to run. This is the core of performance monitoring. See execution_table steps 2 and 4.

What happens if the original method throws an exception?

The exception will propagate unless caught. The timing stops at pjp.proceed(), so duration may not be logged if exception occurs. This is important to handle in real code.

Visual Quiz - 3 Questions

Look at the execution table, what is the value of 'duration' after step 5?

A null

B 1680000000123

C 123 ms

D 1680000000000

💡 Hint

Check the 'duration' variable in variable_tracker after step 5

At which step does the original method actually run?

A Step 2

B Step 3

C Step 5

D Step 6

💡 Hint

Look at the 'Action' column in execution_table for method execution

If pjp.proceed() was not called, what would happen to the 'result' variable?

A It would be null

B It would hold the method's return value

C It would cause a compile error

D It would be set to duration

💡 Hint

See variable_tracker 'result' variable initialization and update

Concept Snapshot

AOP for performance monitoring uses an around advice to intercept method calls.
It records start time, executes the method, records end time, and calculates duration.
The duration is logged for performance insights.
Always call pjp.proceed() to run the original method.
Handle exceptions to ensure timing is accurate.
This helps track slow methods without changing their code.

Full Transcript

Aspect-Oriented Programming (AOP) for performance monitoring intercepts method calls to measure how long they take to execute. The around advice starts a timer before running the method, then stops the timer after the method finishes. It calculates the duration and logs it. The original method is executed by calling pjp.proceed(). Variables like start time, end time, duration, and result track the process. This technique helps developers find slow parts of their application without modifying the original code directly.