[codex] Optimize alarm window preparation loading

[jjoonleo]

Summary

• optimize GET /schedules/alarm-window by preloading preparation data per alarm window instead of resolving it once per schedule
• avoid fetching the full user graph for alarm-window schedule rows; read user spare time once instead
• add query-count regression coverage plus k6 benchmark scripts and a performance note

Root cause

The alarm-window response mapper called preparation repositories per schedule. DEFAULT schedules repeated the same user preparation lookup for every schedule, and the existing user fetch join also triggered repeated inverse UserSetting checks during response mapping.

Evidence

Scenario: 1 user, 25 NOT_ENDED DEFAULT schedules, 3 default preparation steps, k6 10 VUs / 30s, local Spring Boot with H2.

Metric	Before	After	Change
DB prepared statements/request	52	4	-92.3%
HTTP avg latency	5.86 ms	2.83 ms	-51.6%
HTTP p50 latency	3.77 ms	1.99 ms	-47.3%
HTTP p95 latency	14.38 ms	7.08 ms	-50.7%
Throughput	1,559 req/s	2,965 req/s	+90.2%
HTTP failure rate	0.00%	0.00%	no change

See docs/performance/alarm-window-query-count.md for the benchmark setup and notes.

Validation

• ./gradlew check
• ./gradlew test --tests devkor.ontime_back.service.ScheduleAlarmWindowQueryCountTest --tests devkor.ontime_back.service.ScheduleServiceTest

[jjoonleo]

Summary

• optimize GET /schedules/alarm-window by preloading preparation data per alarm window instead of resolving it once per schedule
• avoid fetching the full user graph for alarm-window schedule rows; read user spare time once instead
• add query-count regression coverage plus k6 benchmark scripts and a performance note

Root cause

The alarm-window response mapper called preparation repositories per schedule. DEFAULT schedules repeated the same user preparation lookup for every schedule, and the existing user fetch join also triggered repeated inverse UserSetting checks during response mapping.

Evidence

Scenario: 1 user, 25 NOT_ENDED DEFAULT schedules, 3 default preparation steps, k6 10 VUs / 30s, local Spring Boot with H2.

Metric	Before	After	Change
DB prepared statements/request	52	4	-92.3%
HTTP avg latency	5.86 ms	2.83 ms	-51.6%
HTTP p50 latency	3.77 ms	1.99 ms	-47.3%
HTTP p95 latency	14.38 ms	7.08 ms	-50.7%
Throughput	1,559 req/s	2,965 req/s	+90.2%
HTTP failure rate	0.00%	0.00%	no change

See docs/performance/alarm-window-query-count.md for the benchmark setup and notes.

Validation

• ./gradlew check
• ./gradlew test --tests devkor.ontime_back.service.ScheduleAlarmWindowQueryCountTest --tests devkor.ontime_back.service.ScheduleServiceTest

[jjoonleo]

Summary

• optimize GET /schedules/alarm-window by preloading preparation data per alarm window instead of resolving it once per schedule
• avoid fetching the full user graph for alarm-window schedule rows; read user spare time once instead
• add query-count regression coverage plus k6 benchmark scripts and a performance note

Root cause

The alarm-window response mapper called preparation repositories per schedule. DEFAULT schedules repeated the same user preparation lookup for every schedule, and the existing user fetch join also triggered repeated inverse UserSetting checks during response mapping.

Evidence

Scenario: 1 user, 25 NOT_ENDED DEFAULT schedules, 3 default preparation steps, k6 10 VUs / 30s, local Spring Boot with H2.

Metric	Before	After	Change
DB prepared statements/request	52	4	-92.3%
HTTP avg latency	5.86 ms	2.83 ms	-51.6%
HTTP p50 latency	3.77 ms	1.99 ms	-47.3%
HTTP p95 latency	14.38 ms	7.08 ms	-50.7%
Throughput	1,559 req/s	2,965 req/s	+90.2%
HTTP failure rate	0.00%	0.00%	no change

See docs/performance/alarm-window-query-count.md for the benchmark setup and notes.

Validation

• ./gradlew check
• ./gradlew test --tests devkor.ontime_back.service.ScheduleAlarmWindowQueryCountTest --tests devkor.ontime_back.service.ScheduleServiceTest

[jjoonleo]

Summary

• optimize GET /schedules/alarm-window by preloading preparation data per alarm window instead of resolving it once per schedule
• avoid fetching the full user graph for alarm-window schedule rows; read user spare time once instead
• add query-count regression coverage plus k6 benchmark scripts and a performance note

Root cause

The alarm-window response mapper called preparation repositories per schedule. DEFAULT schedules repeated the same user preparation lookup for every schedule, and the existing user fetch join also triggered repeated inverse UserSetting checks during response mapping.

Evidence

Scenario: 1 user, 25 NOT_ENDED DEFAULT schedules, 3 default preparation steps, k6 10 VUs / 30s, local Spring Boot with H2.

Metric	Before	After	Change
DB prepared statements/request	52	4	-92.3%
HTTP avg latency	5.86 ms	2.83 ms	-51.6%
HTTP p50 latency	3.77 ms	1.99 ms	-47.3%
HTTP p95 latency	14.38 ms	7.08 ms	-50.7%
Throughput	1,559 req/s	2,965 req/s	+90.2%
HTTP failure rate	0.00%	0.00%	no change

See docs/performance/alarm-window-query-count.md for the benchmark setup and notes.

Validation

• ./gradlew check
• ./gradlew test --tests devkor.ontime_back.service.ScheduleAlarmWindowQueryCountTest --tests devkor.ontime_back.service.ScheduleServiceTest

[jjoonleo]

Summary

• optimize GET /schedules/alarm-window by preloading preparation data per alarm window instead of resolving it once per schedule
• avoid fetching the full user graph for alarm-window schedule rows; read user spare time once instead
• add query-count regression coverage plus k6 benchmark scripts and a performance note

Root cause

The alarm-window response mapper called preparation repositories per schedule. DEFAULT schedules repeated the same user preparation lookup for every schedule, and the existing user fetch join also triggered repeated inverse UserSetting checks during response mapping.

Evidence

Scenario: 1 user, 25 NOT_ENDED DEFAULT schedules, 3 default preparation steps, k6 10 VUs / 30s, local Spring Boot with H2.

Metric	Before	After	Change
DB prepared statements/request	52	4	-92.3%
HTTP avg latency	5.86 ms	2.83 ms	-51.6%
HTTP p50 latency	3.77 ms	1.99 ms	-47.3%
HTTP p95 latency	14.38 ms	7.08 ms	-50.7%
Throughput	1,559 req/s	2,965 req/s	+90.2%
HTTP failure rate	0.00%	0.00%	no change

See docs/performance/alarm-window-query-count.md for the benchmark setup and notes.

Validation

• ./gradlew check
• ./gradlew test --tests devkor.ontime_back.service.ScheduleAlarmWindowQueryCountTest --tests devkor.ontime_back.service.ScheduleServiceTest

[jjoonleo]

Summary

• optimize GET /schedules/alarm-window by preloading preparation data per alarm window instead of resolving it once per schedule
• avoid fetching the full user graph for alarm-window schedule rows; read user spare time once instead
• add query-count regression coverage plus k6 benchmark scripts and a performance note

Root cause

The alarm-window response mapper called preparation repositories per schedule. DEFAULT schedules repeated the same user preparation lookup for every schedule, and the existing user fetch join also triggered repeated inverse UserSetting checks during response mapping.

Evidence

Scenario: 1 user, 25 NOT_ENDED DEFAULT schedules, 3 default preparation steps, k6 10 VUs / 30s, local Spring Boot with H2.

Metric	Before	After	Change
DB prepared statements/request	52	4	-92.3%
HTTP avg latency	5.86 ms	2.83 ms	-51.6%
HTTP p50 latency	3.77 ms	1.99 ms	-47.3%
HTTP p95 latency	14.38 ms	7.08 ms	-50.7%
Throughput	1,559 req/s	2,965 req/s	+90.2%
HTTP failure rate	0.00%	0.00%	no change

See docs/performance/alarm-window-query-count.md for the benchmark setup and notes.

Validation

• ./gradlew check
• ./gradlew test --tests devkor.ontime_back.service.ScheduleAlarmWindowQueryCountTest --tests devkor.ontime_back.service.ScheduleServiceTest

[jjoonleo]

Summary

• optimize GET /schedules/alarm-window by preloading preparation data per alarm window instead of resolving it once per schedule
• avoid fetching the full user graph for alarm-window schedule rows; read user spare time once instead
• add query-count regression coverage plus k6 benchmark scripts and a performance note

Root cause

The alarm-window response mapper called preparation repositories per schedule. DEFAULT schedules repeated the same user preparation lookup for every schedule, and the existing user fetch join also triggered repeated inverse UserSetting checks during response mapping.

Evidence

Scenario: 1 user, 25 NOT_ENDED DEFAULT schedules, 3 default preparation steps, k6 10 VUs / 30s, local Spring Boot with H2.

Metric	Before	After	Change
DB prepared statements/request	52	4	-92.3%
HTTP avg latency	5.86 ms	2.83 ms	-51.6%
HTTP p50 latency	3.77 ms	1.99 ms	-47.3%
HTTP p95 latency	14.38 ms	7.08 ms	-50.7%
Throughput	1,559 req/s	2,965 req/s	+90.2%
HTTP failure rate	0.00%	0.00%	no change

See docs/performance/alarm-window-query-count.md for the benchmark setup and notes.

Validation

• ./gradlew check
• ./gradlew test --tests devkor.ontime_back.service.ScheduleAlarmWindowQueryCountTest --tests devkor.ontime_back.service.ScheduleServiceTest

[jjoonleo]

Summary

• optimize GET /schedules/alarm-window by preloading preparation data per alarm window instead of resolving it once per schedule
• avoid fetching the full user graph for alarm-window schedule rows; read user spare time once instead
• add query-count regression coverage plus k6 benchmark scripts and a performance note

Root cause

The alarm-window response mapper called preparation repositories per schedule. DEFAULT schedules repeated the same user preparation lookup for every schedule, and the existing user fetch join also triggered repeated inverse UserSetting checks during response mapping.

Evidence

Scenario: 1 user, 25 NOT_ENDED DEFAULT schedules, 3 default preparation steps, k6 10 VUs / 30s, local Spring Boot with H2.

Metric	Before	After	Change
DB prepared statements/request	52	4	-92.3%
HTTP avg latency	5.86 ms	2.83 ms	-51.6%
HTTP p50 latency	3.77 ms	1.99 ms	-47.3%
HTTP p95 latency	14.38 ms	7.08 ms	-50.7%
Throughput	1,559 req/s	2,965 req/s	+90.2%
HTTP failure rate	0.00%	0.00%	no change

See docs/performance/alarm-window-query-count.md for the benchmark setup and notes.

Validation

• ./gradlew check
• ./gradlew test --tests devkor.ontime_back.service.ScheduleAlarmWindowQueryCountTest --tests devkor.ontime_back.service.ScheduleServiceTest