https://blog.rootsher.dev/en Notes from the engine room: systems, reliability, tooling. Written when the problem turned out to be more interesting than the fix. en-gb Wed, 02 Sep 2026 09:00:00 GMT https://blog.rootsher.dev/en/anatomy-of-a-cpu-problemhttps://blog.rootsher.dev/en/anatomy-of-a-cpu-problemWed, 02 Sep 2026 09:00:00 GMTCapacity & PerformanceOne incident end to end: a 500m request, no limit, no throttling, and p99 climbing from 35 to 180 ms. The whole path of the mechanism.https://blog.rootsher.dev/en/noisy-neighbor-and-cpu-overcommithttps://blog.rootsher.dev/en/noisy-neighbor-and-cpu-overcommitTue, 25 Aug 2026 09:00:00 GMTCapacity & PerformanceOvercommit works until bursts become correlated. An understated request is not only about placement - it is a weaker position under contention.https://blog.rootsher.dev/en/debugging-cpu-in-kuberneteshttps://blog.rootsher.dev/en/debugging-cpu-in-kubernetesTue, 18 Aug 2026 09:00:00 GMTObservabilityUsage, throttling, contention and pressure are four different phenomena. A single CPU chart settles none of them - you need an order of operations.https://blog.rootsher.dev/en/numa-smt-and-cachehttps://blog.rootsher.dev/en/numa-smt-and-cacheTue, 04 Aug 2026 09:00:00 GMTComputer ScienceTwo workloads can get the same CPU time and do different amounts of work. This is where the CPU abstraction ends and the physics of the machine begins.https://blog.rootsher.dev/en/one-cpu-is-not-one-corehttps://blog.rootsher.dev/en/one-cpu-is-not-one-coreTue, 21 Jul 2026 09:00:00 GMTContainersCPU time and CPU placement are two different mechanisms. A limit says how much you may consume; affinity and cpuset say where a task may execute.https://blog.rootsher.dev/en/requests-limits-and-qoshttps://blog.rootsher.dev/en/requests-limits-and-qosTue, 07 Jul 2026 09:00:00 GMTContainersA QoS class is the result of how requests and limits are configured, not a separate CPU allocation mechanism. Guaranteed is not a dedicated core.https://blog.rootsher.dev/en/psi-cpu-pressurehttps://blog.rootsher.dev/en/psi-cpu-pressureTue, 23 Jun 2026 09:00:00 GMTObservabilityUtilisation says how much CPU a workload got. PSI measures the time it lost because it wanted to execute and had nothing to execute on.https://blog.rootsher.dev/en/cpu-contentionhttps://blog.rootsher.dev/en/cpu-contentionTue, 09 Jun 2026 09:00:00 GMTCapacity & PerformanceWith no limit at all a process can sit and wait. All it takes is runnable demand exceeding available capacity - and you only see it in latency.https://blog.rootsher.dev/en/cpu-limits-and-throttlinghttps://blog.rootsher.dev/en/cpu-limits-and-throttlingTue, 26 May 2026 09:00:00 GMTContainersA limit does not pin a container to a core. It gives it a CPU-time budget accounted per period, and once that runs out the kernel throttles it.https://blog.rootsher.dev/en/cpu-requests-in-kuberneteshttps://blog.rootsher.dev/en/cpu-requests-in-kubernetesTue, 12 May 2026 09:00:00 GMTContainersA request is a declaration of demand, not a ceiling. It feeds placement in kube-scheduler and CPU weight on the kernel side.https://blog.rootsher.dev/en/cgroups-and-cpuhttps://blog.rootsher.dev/en/cgroups-and-cpuTue, 28 Apr 2026 09:00:00 GMTInfrastructureGroup scheduling, cpu.weight and hierarchy - how the kernel divides CPU between groups of processes instead of individual tasks.https://blog.rootsher.dev/en/how-linux-gives-a-process-cpuhttps://blog.rootsher.dev/en/how-linux-gives-a-process-cpuTue, 14 Apr 2026 09:00:00 GMTComputer ScienceA process does not "have CPU". It is ready to run, and the scheduler decides when it actually gets processor time.https://blog.rootsher.dev/en/cpu-in-kubernetes-from-the-kernel-uphttps://blog.rootsher.dev/en/cpu-in-kubernetes-from-the-kernel-upTue, 07 Apr 2026 09:00:00 GMTCapacity & PerformanceA CPU model built bottom-up: from runnable tasks and the scheduler, through cgroups, requests and limits, to throttling, contention, PSI and diagnostics.https://blog.rootsher.dev/en/rendering-as-compositionhttps://blog.rootsher.dev/en/rendering-as-compositionTue, 11 Nov 2025 09:00:00 GMTFrontendRendering stopped being a single stage. It is the placement of work across time, space and runtimes, and the framework is a consequence of those decisions.https://blog.rootsher.dev/en/server-componentshttps://blog.rootsher.dev/en/server-componentsTue, 08 Jul 2025 09:00:00 GMTFrontendThe rendering boundary stops running through the page and starts running through the module graph. Some components never have a client-side implementation.https://blog.rootsher.dev/en/resumabilityhttps://blog.rootsher.dev/en/resumabilityTue, 11 Mar 2025 09:00:00 GMTFrontendThe server records enough information that the client never rebuilds the component tree. Code loads because execution became necessary.https://blog.rootsher.dev/en/islands-architecturehttps://blog.rootsher.dev/en/islands-architectureTue, 12 Nov 2024 09:00:00 GMTFrontendThe starting point stops being the application. The page is a document, and only the fragments that truly need a client runtime get one.https://blog.rootsher.dev/en/selective-and-progressive-hydrationhttps://blog.rootsher.dev/en/selective-and-progressive-hydrationTue, 09 Jul 2024 09:00:00 GMTFrontendHydration stops being one startup task. Client CPU becomes a resource allocated by priority and by the user's real intent.https://blog.rootsher.dev/en/edge-renderinghttps://blog.rootsher.dev/en/edge-renderingTue, 12 Mar 2024 09:00:00 GMTFrontendMoving compute closer to the user only pays off when the data travels with it. Otherwise we shorten one hop and lengthen the rest.https://blog.rootsher.dev/en/partial-prerenderinghttps://blog.rootsher.dev/en/partial-prerenderingTue, 14 Nov 2023 09:00:00 GMTFrontendThe route stops being the unit of decision. A static shell is produced earlier, dynamic fragments arrive at request time or through the stream.https://blog.rootsher.dev/en/streaming-ssrhttps://blog.rootsher.dev/en/streaming-ssrTue, 09 May 2023 09:00:00 GMTFrontendThe response stops being atomic. The server sends finished fragments and the slowest dependency no longer blocks the entire document.https://blog.rootsher.dev/en/revalidation-and-isrhttps://blog.rootsher.dev/en/revalidation-and-isrTue, 10 Jan 2023 09:00:00 GMTFrontendISR is not a separate rendering category but a cache with controlled inconsistency: precomputed HTML, expiration and regeneration.https://blog.rootsher.dev/en/deferred-generationhttps://blog.rootsher.dev/en/deferred-generationTue, 13 Sep 2022 09:00:00 GMTFrontendThe request stops being the moment of rendering and becomes a trigger for materialising an artifact. The first user pays, everyone after gets a file.https://blog.rootsher.dev/en/static-site-generationhttps://blog.rootsher.dev/en/static-site-generationTue, 10 May 2022 09:00:00 GMTFrontendBuild-time rendering trades request cost for build cost. You pay once, serve cheaply, and start having a data freshness problem.https://blog.rootsher.dev/en/hydrationhttps://blog.rootsher.dev/en/hydrationTue, 11 Jan 2022 09:00:00 GMTFrontendThe server sends the result of rendering, not the application. The browser has to rebuild the component tree and wire it to the existing DOM.https://blog.rootsher.dev/en/ssr-returnshttps://blog.rootsher.dev/en/ssr-returnsTue, 14 Sep 2021 09:00:00 GMTFrontendThe server renders the first view not to make the frontend disappear, but to make content exist earlier. The rest of the cost stays on the client.https://blog.rootsher.dev/en/the-cost-of-shipping-the-applicationhttps://blog.rootsher.dev/en/the-cost-of-shipping-the-applicationTue, 11 May 2021 09:00:00 GMTFrontendTransfer size is the first cost, not the only one. What counts is the work the device must do before the application becomes usable.https://blog.rootsher.dev/en/spa-and-client-side-renderinghttps://blog.rootsher.dev/en/spa-and-client-side-renderingTue, 12 Jan 2021 09:00:00 GMTFrontendThe browser downloads the document once and manages screen transitions itself. The frontend stops being a presentation layer and becomes a long-lived runtime.https://blog.rootsher.dev/en/ajax-and-the-first-dynamic-clientshttps://blog.rootsher.dev/en/ajax-and-the-first-dynamic-clientsTue, 08 Sep 2020 09:00:00 GMTFrontendA request stopped meaning navigation. The browser keeps the current document alive and decides for itself what to do with the server's answer.https://blog.rootsher.dev/en/server-rendered-webhttps://blog.rootsher.dev/en/server-rendered-webTue, 12 May 2020 09:00:00 GMTFrontendThe server assembled a full document for every request and the browser was a document renderer. A simple model, as long as the whole document could be the unit…