After overnight idle time, the first call to a parks-department Oracle Function takes several seconds, while immediate follow-up calls return much faster. What explains the slow first invoke?
Select an answer to reveal the explanation.
Short Explanation
Like opening a closed community center before the first visitor, the platform must spin up execution space after idle time. That cold start can take seconds; reuse of the same infrastructure makes later calls hot and snappy.
Full Explanation
After overnight idle, the parks-department function’s first call often waits while Oracle Functions provisions execution infrastructure—containers, runtime, and related capacity. That delay is a cold start. Subsequent invokes that reuse the still-warm infrastructure are hot starts and typically return much faster. The behavior matches the observed pattern: slow first call, snappy follow-ups without any application-level warm-up ritual.
The FDK does not require an explicit warm-up call in handler code after every idle period; cold start is a platform lifecycle concern. OCI Monitoring metric scrape timing is unrelated to why the first business invoke is slow. API Gateway may add its own overhead when used as a front door, but it does not impose a fixed multi-second handshake that explains Functions cold starts when the function is invoked after idle.
Exam caveat: cold-start cost varies with image size, language runtime, and idle duration—Java and large images often feel worse than tiny native handlers. Operational check: capture invoke latency histograms after a known idle window, distinguish first-invoke versus steady-state latency, and decide whether provisioned concurrency is warranted for user-facing parks APIs versus accepting occasional cold starts for batch-style work.