https://www.dhaval-shah.com/categories/performance-engineering/Recent content in performance-engineering on Dhaval ShahHugo -- gohugo.ioSat, 25 Jul 2026 01:00:50 +0000https://www.dhaval-shah.com/sre-gc-ai-review/Sat, 25 Jul 2026 01:00:50 +0000https://www.dhaval-shah.com/sre-gc-ai-review/Background An older post on this blog covered the technical details of this incident - the GC types, the flags, the before-and-after metrics. This post covers something different: the process of how the investigation ran, where it lost time, and which decisions (with more structured approach) would have changed. The incident On Black Friday, an online checkout platform running at over 1000 TPS. CPU spiking to 100%, application crashing. Restarted every 12 hours to keep the business running while the team investigated.https://www.dhaval-shah.com/db-optimization-ai-review/Mon, 06 Jul 2026 01:00:50 +0000https://www.dhaval-shah.com/db-optimization-ai-review/Background My earlier article on AI augmented Fintech post-mortem review walked through an Oracle JSON storage problem: a payment transaction table stored as JSON, a query that needed to filter on a nested field, and the chain of fixes - that the team eventually needed. Out of curiosity - a reasonable question came out of that post: does Postgres have the same problem? The honest answer is partly yes, partly no.https://www.dhaval-shah.com/gc-comparison-ai-review/Sun, 21 Jun 2026 02:00:50 +0000https://www.dhaval-shah.com/gc-comparison-ai-review/Background My old article compared Virtual Thread based implementations of Spring Core Reactor and JDK 21, building on the comparative analysis before it. Both articles measured the usual things - total processing time, memory footprint, GC pauses, CPU time - and both relied on the summary report generated by GCEasy. The conclusion from that data was straightforward: JDK based implementation requires more GC activity and a heavier memory footprint, but this does not have any significant impact on application performance.