A PDF-merge Lambda for council packets is CPU-bound and slow at 128 MB. What should the developer remember when tuning memory?
Select an answer to reveal the explanation.
Short Explanation
On Lambda, memory is the volume knob that also turns up CPU—more RAM, more compute horsepower for that PDF mash-up. Don't guess 128 MB forever or assume memory and CPU are strangers; profile, raise memory, and measure duration and cost together.
Full Explanation
A PDF-merge Lambda for council packets that is CPU-bound and slow at 128 MB should remember that raising configured memory also raises CPU allocation, so profile and size based on measurements. On Lambda, memory is the knob that scales CPU and network throughput for the execution environment. Under-sized memory starves CPU-heavy PDF work; over-sizing wastes money. Empirical profiling with different memory settings finds the cost/latency sweet spot for monthly packet builds.
The claim that memory and CPU are unrelated—and that only timeout affects CPU share—is false on Lambda. Lowering memory does not increase CPU allocation for compute-heavy work; it reduces it. Keeping CPU-bound functions at 128 MB and scaling only with reserved concurrency may add parallel invocations but does not give each invoke more CPU for a single large merge.
Exam caveat: more memory reduces duration enough that total cost sometimes falls despite a higher GB-second rate—measure both. Timeout must still exceed worst-case duration after sizing. Power Tuning tools can automate experiments in non-prod.
Operational check: run representative council-packet merges at several memory settings; record duration and cost; pick the measured optimum; set timeout with headroom; and revisit sizing when packet templates change materially.