Ankur Mhatre
958b401f0f
Adds spring-boot-startup-time/, the companion project for BLOG-618: a runnable Spring Boot 4.1.1 application on JDK 25 that installs BufferingApplicationStartup and FlightRecorderApplicationStartup behind a system property, and a /diag/startup endpoint that computes step self time -- the number /actuator/startup does not give you and the one that names the actual culprits. Captured under docs/output/: the step tree sorted both ways, the same startup as JFR events, a +5000-class experiment putting 0.11 ms per scanned class on the classpath scan tax, the silent truncation a 2048-step buffer performs, and JDK 25 AOT cache timings (6.93 s to 4.82 s). Post body and metadata live in post/. Moves the existing Actuator project into actuator-in-production/ so the repository holds one directory per article; the root README is now an index.
63 lines
2.4 KiB
Markdown
63 lines
2.4 KiB
Markdown
# 01 — The number Boot logs, and what it hides
|
|
|
|
next → [02 — Turning instrumentation on](02-turning-instrumentation-on.md)
|
|
|
|
---
|
|
|
|
Every Spring Boot application ends its startup with one line:
|
|
|
|
```
|
|
Started StartupDiagnosisApplication in 6.6 seconds (process running for 7.4)
|
|
```
|
|
|
|
Two numbers. The first is measured from the `SpringApplication.run()` call to the
|
|
`ApplicationReadyEvent`. The second is `ManagementFactory.getRuntimeMXBean().getUptime()`,
|
|
so the gap between them is JVM bootstrap: opening the jar, verifying classes, starting the
|
|
JIT — work that happens before your code runs at all.
|
|
|
|
Neither number tells you where the 6.6 seconds went, and the usual next move — reading the
|
|
log timestamps — is worse than it looks. The log only shows you components that chose to
|
|
log. This application spends about half a second inside `tariffCacheWarmer` and logs
|
|
nothing while doing it. On the timeline it is a silent gap between two Hibernate lines,
|
|
and you would reasonably conclude that Hibernate was slow.
|
|
|
|
## What is actually available
|
|
|
|
Spring Framework has carried an `ApplicationStartup` SPI since 5.3. It is a tracing
|
|
interface with one method that matters:
|
|
|
|
```java
|
|
public interface ApplicationStartup {
|
|
StartupStep start(String name);
|
|
}
|
|
```
|
|
|
|
Framework and Boot call it at about two dozen named points — `spring.beans.instantiate`,
|
|
`spring.context.config-classes.parse`, `spring.data.repository.proxy`, and so on — tagging
|
|
each step with the bean name or class count involved. Steps nest, so what you get is a
|
|
tree, not a list.
|
|
|
|
The default implementation, `DefaultApplicationStartup`, does nothing. That is the whole
|
|
reason startup profiling feels unavailable: the instrumentation is already in your
|
|
application and is switched off.
|
|
|
|
Two implementations record it:
|
|
|
|
| Implementation | Where it lives | Output |
|
|
|---|---|---|
|
|
| `BufferingApplicationStartup` | `spring-boot` | in-memory buffer, read over HTTP |
|
|
| `FlightRecorderApplicationStartup` | `spring-core` | JFR events in a `.jfr` file |
|
|
|
|
There is no third option and no third-party agent needed.
|
|
|
|
## What this repository measures
|
|
|
|
The application here is deliberately ordinary: web, JPA over H2, three repositories, and
|
|
four beans that do real work on the way up. It starts in about 6.6 seconds on the machine
|
|
that produced [`docs/output/`](output). Every figure in the article and in these chapters
|
|
came from a file in that directory.
|
|
|
|
---
|
|
|
|
next → [02 — Turning instrumentation on](02-turning-instrumentation-on.md)
|