标签：#Performance

A bot on Polymarket quietly extracted $32k in near risk-free profits by sniping “Will Company XYZ Beat Earnings?” markets. It waits for the official release, then instantly buys the winning side. Many limit orders from retail traders remain uncancelled, creating a post-announcement arbitrage window. Two developers decided to challenge it. Here’s what they learned while trying to build a faster version. Infrastructure Choices Location : Polymarket’s CLOB runs in AWS eu-west-2 (London). They deployed from Ireland (eu-west-1, Dublin) — the closest realistic option without IP tricks. UK IPs are blocked. Language : Rust for type safety and speed. The author notes you can achieve competitive latency in Python if you strip unnecessary network calls. Key Warning : Avoid the official Polymarket SDKs for ultra-low latency. They include helpful but slow pre-trade checks. Build lean custom clients. The Data Feed Challenge (The Real Bottleneck) The critical edge is getting earnings announcements faster than competitors. Source Performance Verdict Scraping Newswires Too slow Failed Benzinga Low-Latency Slower than manual clicking Failed Paid ultrafast feed ~500ms after release Still too slow EDGAR Consistently slower than newswires Backup only Even at 500ms, the order book was already swept by faster bots. The top players are likely using extremely expensive dedicated feeds or custom setups. Technical Lessons Learned Network > Code Most latency lives in the network round-trip, not in language choice. Optimize transport first. Custom Execution Layer Skip heavy SDK abstractions. Direct signed orders with minimal validation. Post-Event Sniping Logic Monitor newswire feeds aggressively Parse EPS vs. estimate instantly Place aggressive limit/market orders on the winning side Handle cases with ambiguity (multiple interpretations of “beat”) Reality Check They made some wins during EPS ambiguity or when faster bots hit size limits, but never won on pure speed against the leader. Why This

MVCC, WAL, vacuum, and replication slots under sustained delete load - and how to delete billions of rows without your database noticing Most "how to delete a lot of rows" articles stop at "batch it and delete children before parents." That advice is correct, it's table stakes, and everyone already knows it. This article is about everything after that - the parts that actually decide whether your cleanup runs quietly in the background for a week or pages you at 3 a.m. with a full disk and a replica that's six hours behind. The thesis: at scale, your DELETE statement is the easy part. The adversaries are the subsystems a delete feeds - MVCC tuple versioning, the write-ahead log, autovacuum, and the replication machinery. Bulk deletion is really an exercise in flow control across those subsystems . Get the SQL right and the systems wrong, and you'll still take production down. We'll assume PostgreSQL (the internals are PG-specific), a live OLTP primary with at least one physical replica and one or more logical/CDC consumers, and a target of hundreds of millions to billions of rows across many related tables. The one paragraph of "basics," so we can move on: delete in dependency order (referencing rows before referenced rows); collect parent keys once; never rely on ON DELETE CASCADE for huge deletes because you can't throttle a cascade. Done. Now the real material. 1. What a DELETE actually costs A delete is not "remove a row." Under MVCC it's "mark a row version dead and write that fact everywhere." For each deleted tuple, PostgreSQL: Sets xmax on the heap tuple to your transaction id. The row is still physically present; it becomes a dead tuple once your transaction commits and no snapshot can still see it. Writes a WAL record for the heap change. If this is the first modification of that page since the last checkpoint, it also writes a full-page image (FPI) - potentially 8 KB of WAL for a single-row change. Touches every index. Index entries aren't removed at delet

Every backend engineer has seen this happen, you build an application on a relational database like MySQL, handling thousands of concurrent transactions effortlessly. Then, the business asks for a real time analytics dashboard. But when you run an aggregation query over historical data, suddenly the database that effortlessly managed live traffic starts thrashing, evicting your working set, and dragging application performance down. This isn't a tuning problem, a missing index, or a badly written query. It’s a fundamental architectural collision. OLTP (Online Transaction Processing) OLTP encompasses nearly every concurrent digital interaction triggered across a distributed system. A user downloading a PDF, a microservice firing an automatic maintenance log, a comment on a social feed these are all transactions. Data engineers rely on OLTP systems (like MySQL or PostgreSQL) to capture these concurrent streams of interactions for creating , updating and deleting records. The Tree Based In-Place Engine To reliably capture massive volumes of transactions without corrupting data or locking up the application, OLTP systems rely on a highly optimized, row oriented architecture built around the B+ Tree. Because they must provide immediate, atomic updates to existing records, transactional databases manage state through a strict sequence of physical tree traversal and in-memory page mutation: The B+ Tree Indexing: When a transaction reads or updates id: 1, the engine traverses a B+ Tree from the root, through the branch nodes, directly to the specific physical leaf node holding that row. This O(\log n) traversal guarantees a fast, isolated point-lookup. It ensures the application always hits the single version of the row without scanning irrelevant data. The Buffer Pool & In-Place Updates: OLTP systems perform in place updates. The database pulls the exact page containing id: 1 from the physical disk into memory (the Buffer Pool). The specific row is mutated directly in RAM

You have 50 documents and you're running them through an LLM in a loop. The first one finishes at the 2-second mark. The fiftieth finishes at the 100-second mark — not because it's harder, but because it waited in line behind the other 49. Pool runs all 50 at the same time. The Problem With Loops Every developer who works with LLMs writes this code eventually: import os from yait_aichain.models import Model from yait_aichain.skills import Skill skill = Skill ( model = Model ( " claude-sonnet-4-6 " , api_key = os . getenv ( " ANTHROPIC_API_KEY " )), input = { " messages " : [{ " role " : " user " , " parts " : [ " Summarise in two sentences: \n\n {text} " ]}]}, ) documents = [{ " text " : f " Document { i } content... " } for i in range ( 50 )] results = [] for doc in documents : result = skill . run ( doc ) results . append ( result ) It works. It's readable. And it's painfully slow. Each LLM call takes roughly 2 seconds. Multiply that by 50 documents and you're staring at your terminal for almost two minutes. The calls are completely independent — document 37 doesn't need the result of document 12. Yet document 37 sits idle, waiting its turn. That's a scheduling problem, not a computation problem. I ran into this directly while building a task that pulled N files or links and produced a consolidated report. The sequential version was logically fine but just hemorrhaged time. I needed to fire everything at once without rewriting the Skill logic — no new prompt templates, no restructured code, just a different execution model. That's what Pool is. Pool: Parallel Map for LLM Calls Pool takes one Skill (or Chain) and a list of inputs , then launches all of them concurrently. Think of it as Array.map() where every element runs in parallel against an LLM. import os from yait_aichain.models import Model from yait_aichain.skills import Skill from yait_aichain.pool import Pool , DONE , FAILED skill = Skill ( model = Model ( " claude-sonnet-4-6 " , api_key = os . getenv ( "

The obsession with centralizing heavy compute on backend servers is a massive bottleneck for both cost and latency. In 2026, as more applications move to the edge, developers are realizing that the user's browser is an incredibly powerful, untapped compute engine. Recently, I challenged myself to build a free live chess game analyzer for my developer utility suite, CipherKit. The traditional architecture for this requires passing FEN strings to a dedicated backend cluster running the Stockfish engine, which introduces network latency and scales operational costs linearly. I wanted to achieve a 100% client-side, zero-latency experience. Here is how I offloaded the heavy lifting entirely to the browser edge. The Architecture: WASM + Web Workers Running a heavy calculation engine directly in JavaScript instantly blocks the main UI thread. To achieve a flawless 60fps UI, I completely decoupled the state from the computation. The UI Thread: Handles strict DOM rendering, board states, and piece animations. The Worker Thread: Instantiates the Stockfish engine via WebAssembly within the browser's memory. When a live game update occurs, the main thread fires a simple FEN payload via worker.postMessage() . The Worker processes the deep-line evaluations (Depth 20+) asynchronously in the background. It then streams the evaluation lines back to the main thread without causing a single micro-freeze. The Result By treating the browser as the edge compute layer, the tool achieves: Zero Server Latency: Bypassing API rate limits and network bottlenecks. $0 Infrastructure Cost: Heavy compute is crowd-sourced to the user's local device. Absolute Privacy: Sensitive payloads never leave the browser. If you want to see this local asynchronous thread management in action, you can test the live analyzer (and inspect the network tab) here: 👉 CipherKit Live Chess Analyzer Are you offloading heavy computations to the client side in your current projects, or are you still relying on traditional

A receiver pulling a UDP feed was missing roughly 30% of its messages. No errors, no exceptions, no stack traces — just gaps in the sequence numbers. The first suspect is always the network: a flaky switch, a saturated link, a tired NIC. The network was innocent. The packets were being dropped on the receiving host , after they'd already arrived. Here's how to tell the difference, and why it matters. Why UDP makes this sneaky UDP has no retransmission and no backpressure. When a datagram is lost, nobody is notified — not the sender, not the receiver. The packet simply isn't there. That means two completely different failures look identical from the application's point of view: The network dropped the packet before it reached your machine. Your own host accepted the packet and then threw it away after it arrived. The application sees the same thing in both cases: a missing sequence number. But the fix is in a different building depending on which one it is. Where the packets actually go The receive path is: NIC → kernel socket receive buffer → your recv() call. The kernel parks incoming datagrams in a per-socket buffer until your code reads them. If your code doesn't drain that buffer fast enough, it fills, and the kernel drops the overflow. Crucially, the kernel counts those drops. On Linux: # Per-protocol summary — look for "receive buffer errors" netstat -su # Or straight from the kernel counters cat /proc/net/snmp | grep -A1 Udp # InDatagrams ... InErrors RcvbufErrors ... If RcvbufErrors is climbing, the network did its job and your host discarded the datagrams. That single counter collapses a week of "is it the switch?" into about ten seconds of certainty. The actual cause In this case the socket receive buffer was sitting at the default (~208 KB). The sender burst faster than a single receive thread could call recv() . Average throughput looked fine on every dashboard — but the bursts filled the buffer in milliseconds, and everything past the brim was dropped.

Magento's default Luma checkout loads a heavy Knockout.js stack, dozens of RequireJS modules, and payment iframes that fight for the main thread. For merchants where checkout is the conversion bottleneck, shaving seconds off load and interaction time pays back faster than another homepage hero image. We rebuilt checkout in React— React Checkout Pro —for Magento 2 and Hyvä stores that needed Shopify-like speed without leaving Adobe Commerce. Here is what we measured, what surprised us, and what we would do differently. The problem: checkout is where Core Web Vitals go to die Homepage optimizations are table stakes. Checkout is different: More JavaScript. Payment methods, validators, shipping step observers, and third-party scripts stack on one route. More layout shift. Address suggestions, shipping method lists, and tax updates re-render large DOM regions. More input delay. Autocomplete plugins, reCAPTCHA, and BNPL widgets compete on keydown handlers. On a representative Luma checkout (mid-size US retailer, ~80 SKUs in catalog, 4 payment methods), lab tests before migration showed: Metric Luma checkout (before) React checkout (after) LCP (lab, 4G) 4.8s 2.1s INP (field interaction) 320ms 95ms CLS (full flow) 0.18 0.04 JS transferred (checkout route) ~1.9 MB ~420 KB Time to interactive (est.) 6.2s 2.8s Field data from CrUX lagged lab wins by 4–6 weeks but trended the same direction once cache and CDN rules settled. Your numbers will differ. The pattern we see repeatedly: the biggest win is shipping less JavaScript to checkout , not micro-optimizing the JavaScript you keep. Architecture: React island, Magento brain We did not headless the entire storefront. Magento still owns: Quote totals and tax calculation Shipping rate requests Payment tokenization and order placement APIs Customer session and cart persistence React owns the UI layer: step navigation, form state, validation UX, and optimistic updates while Magento APIs catch up. High-level flow: Browser → React Chec

TL;DR: HTML-first means shipping real, server-rendered content before any JavaScript runs, then adding scripts only where they earn their place. In 2026 this approach is winning again, not out of nostalgia, but because the median mobile page now ships around 646 KB of JavaScript, fewer than half of mobile sites pass Core Web Vitals, and the browser already does natively what many sites still pull in libraries for. For most business websites, progressive enhancement is faster to ship, cheaper to run, and easier to keep alive. Sometime in 2026, "just use HTML" stopped being a contrarian take. I noticed it first in my own client work, not in a conference talk. The sites that start close to the platform, plain HTML, forms, links, server rendering, and add JavaScript only where it genuinely helps, are the ones that launch faster, load cleaner, and generate fewer confused support messages two months later. This is not anti-JavaScript. It is a reaction to a decade of reaching for a framework before asking whether the project needed one. The pendulum is swinging back toward the browser, and the numbers explain why. What HTML-first actually means (and why it is not 2009 web design) The fastest way to misunderstand this is to picture table layouts and inline styles. That is not it. HTML-first is an order of operations. You build a page that is complete and usable as server-rendered HTML, then you enhance it. The content is readable before a single script loads. The form submits even if JavaScript never arrives. This is the old idea of progressive enhancement , applied deliberately with modern tools instead of by accident. There is a small but real movement around this now. The HTML First community manifesto argues, fairly, that the platform has far more capability than most teams use. You do not have to agree with every line of it to notice the shift. The point is not to ban JavaScript. The point is to stop treating it as the default starting material for every page. The 2026

I inherited a SQL Server database with 2.3 million rows. Queries took 45 seconds. Users were frustrated. Dashboards timed out. Here is exactly what I did. Step 1: Find the slowest queries I used SQL Server's query store to identify the top 10 worst performing queries. Step 2: Check the execution plan Missing index warnings everywhere. Also saw table scans on a 2 million row table. Step 3: Add targeted indexes Created two non-clustered indexes on the most filtered columns. No over-indexing. Just what the queries actually needed. Step 4: Rewrite the worst join One query was joining 6 tables with a cross apply that made no sense. Restructured to inner joins with proper filter ordering. The result 45 seconds down to 8 seconds. An 82% improvement. Real-time dashboards started working again. Key lesson Check what is actually slow before changing anything. Most people skip this and waste time optimizing the wrong thing. What is your fastest query optimization win?

I inherited a SQL Server database with 2.3 million rows. Queries took 45 seconds. Users were frustrated. Dashboards timed out. Here is exactly what I did. Step 1: Find the slowest queries I used SQL Server's query store to identify the top 10 worst performing queries. Step 2: Check the execution plan Missing index warnings everywhere. Also saw table scans on a 2 million row table. Step 3: Add targeted indexes Created two non-clustered indexes on the most filtered columns. No over-indexing. Just what the queries actually needed. Step 4: Rewrite the worst join One query was joining 6 tables with a cross apply that made no sense. Restructured to inner joins with proper filter ordering. The result 45 seconds down to 8 seconds. An 82% improvement. Real-time dashboards started working again. Key lesson Check what is actually slow before changing anything. Most people skip this and waste time optimizing the wrong thing. What is your fastest query optimization win?

I Cut My Next.js + Supabase App Load Time by 73% - Here Are the 5 Techniques That Actually Worked Last month, our SaaS dashboard was embarrassingly slow . 4.2 seconds to load the main page. Users were complaining. Conversion rates were tanking. Today? 1.1 seconds . 73% faster. Here's exactly what worked (and what didn't). The Problem: Death by a Thousand Database Calls Our dashboard showed user projects, team members, recent activity, and notifications. Sounds simple, right? Wrong. Each component was making its own database calls. The projects list fetched projects, then made separate calls for each project's stats. The activity feed loaded events, then fetched user details for each event. Classic N+1 query problem, but worse. Technique #1: Strategic Data Fetching Consolidation Before: 47 database calls to load the dashboard After: 3 database calls The fix wasn't fancy. We consolidated related data into single queries using Supabase's nested select syntax: // ❌ Before: Multiple separate calls const projects = await supabase . from ( ' projects ' ). select ( ' * ' ) const stats = await Promise . all ( projects . map ( p => supabase . from ( ' project_stats ' ). select ( ' * ' ). eq ( ' project_id ' , p . id )) ) // ✅ After: Single consolidated call const projects = await supabase . from ( ' projects ' ) . select ( ` *, project_stats(*), team_members(count), recent_activity:activities(*, user:users(name, avatar_url)) ` ) . limit ( 10 ) Result: Dashboard load time dropped from 4.2s to 2.8s (33% improvement) Technique #2: Aggressive Caching with Smart Invalidation Most dashboard data doesn't change every second. We implemented a three-tier caching strategy: // Static data: Cache indefinitely const categories = await supabase . from ( ' categories ' ) . select ( ' * ' ) . cache ({ revalidate : false }) // Semi-static data: Cache with revalidation const userProjects = await supabase . from ( ' projects ' ) . select ( ' * ' ) . eq ( ' user_id ' , userId ) . cache ({ revali

Next.js + Supabase Performance Optimization: From Slow to Lightning Fast Last month, I optimized a Next.js + Supabase application that was frustratingly slow. Initial page load took 4.2 seconds, Lighthouse performance score was 62, and users were complaining. After applying these optimization techniques, we achieved: 70% faster load times (4.2s → 1.3s) Lighthouse score of 96 (up from 62) LCP improved by 65% (3.8s → 1.3s) 50% reduction in database queries Here's exactly how we did it. The Starting Point: Measuring Performance Before optimizing anything, we measured current performance using: Lighthouse (Chrome DevTools): Performance: 62 First Contentful Paint (FCP): 2.1s Largest Contentful Paint (LCP): 3.8s Total Blocking Time (TBT): 420ms Cumulative Layout Shift (CLS): 0.18 Real User Monitoring: Average page load: 4.2s Time to Interactive: 5.1s Database query time: 850ms average The Problems: Unoptimized database queries No caching strategy Large JavaScript bundles Unoptimized images Blocking render paths Too many client-side fetches Let's fix each one. 1. Database Query Optimization Problem: N+1 Queries The biggest performance killer was N+1 queries. We were fetching posts, then fetching the author for each post individually. // ❌ Bad: N+1 queries (1 + N database calls) async function getPosts () { const { data : posts } = await supabase . from ( ' posts ' ) . select ( ' id, title, author_id ' ) // Fetching author for each post = N queries const postsWithAuthors = await Promise . all ( posts . map ( async ( post ) => { const { data : author } = await supabase . from ( ' users ' ) . select ( ' name, avatar ' ) . eq ( ' id ' , post . author_id ) . single () return { ... post , author } }) ) return postsWithAuthors } Impact: 50 posts = 51 database queries (850ms total) Solution: Use Joins // ✅ Good: Single query with join (1 database call) async function getPosts () { const { data : posts } = await supabase . from ( ' posts ' ) . select ( ` id, title, author:users(nam

A few days ago I finished benchmarking something I've been building - a cache-aware, stable, histogram-based sorting algorithm I'm calling BusSort . The results surprised even me. At 100 million elements, it runs ~2x faster than Java's Dual-Pivot Quicksort on random data - while being stable . Dual-Pivot QS is not. The Problem With Quicksort at Scale Quicksort-based algorithms partition elements with random writes across the entire array. At large scales this causes cache thrashing - elements are being written to memory locations all over the place, constantly missing L1 and L2 cache. The larger the array, the worse it gets. The Core Idea Instead of scattering elements globally, BusSort processes data in L1 cache-sized chunks - 4096 integers (~16KB). For each chunk, it does 4 passes: PASS 1 - Scan left-to-right, compute bucket for each element, build a local histogram PASS 2 - Compute local prefix sums (bucket positions within the chunk) PASS 3 - Scatter into a local grouped buffer - because this buffer is L1-sized, all random writes stay in cache ✅ PASS 4 - Copy each bucket's portion to its correct global position With 128-way splitting , recursion depth stays at just ~4 levels even for 100M elements. Base case: Insertion Sort for ≤ 1024 elements. On the benchmark machine (i5-1135G7, 48KB L1 data cache): 4096 × 3 × 4 bytes = 49,152 bytes ≈ 48KB The three working arrays fit exactly in L1. Not a coincidence. Benchmark Results Tested against Arrays.sort(int[]) - Java's Dual-Pivot Quicksort . n = 100,000,000 | Java 17 | i5-1135G7 @ 2.40GHz Input Type BusSort Dual-Pivot QS Ratio Random 3991ms 8604ms ~2x Sorted 57ms 104ms ~2x Reverse 280ms 166ms 0.6x Nearly Sorted 2452ms 2789ms ~1.1x Duplicates 712ms 2242ms ~2.4x Few Duplicates 1295ms 3185ms ~2.3x All Same 51ms 32ms 0.6x Clustered 1419ms 2242ms ~1.6x Consistently faster on most input types. Stable. Zero comparison overhead. The two losses (Reverse, All Same) are where Dual-Pivot QS has structural advantages - run detecti

Something is slow. Maybe a page takes forever to load, maybe a migration is hanging, maybe your Supabase dashboard just spins. You suspect a query is stuck somewhere in your database, but you can't see what's happening — Postgres doesn't exactly surface this on its own. Turns out it does. You just need to ask. Seeing what's running Postgres keeps track of every active connection and what it's doing in a system view called pg_stat_activity . You can query it like any table: SELECT pid , state , query , age ( clock_timestamp (), query_start ) AS duration FROM pg_stat_activity WHERE state != 'idle' ORDER BY duration DESC ; That gives you every non-idle process — its process ID, current state, the SQL it's running, and how long it's been at it. If something has been running for minutes when it should take milliseconds, you've found your problem. A few things worth knowing about the columns: pid — the process ID, which you'll need if you want to kill it state — usually active (running right now), idle in transaction (sitting inside an open transaction doing nothing), or idle (waiting for work) query — the actual SQL text query_start — when the current query began If you want to include the user and database to narrow things down: SELECT pid , usename , datname , state , query , age ( clock_timestamp (), query_start ) AS duration FROM pg_stat_activity WHERE state != 'idle' ORDER BY duration DESC ; The dangerous one — idle in transaction An active query that's been running for a while is usually just slow. An idle in transaction connection is a different kind of problem — it means someone (or some code) opened a transaction and never committed or rolled it back. The connection is doing nothing, but it's still holding locks, which can block other queries from running. These are the ones that tend to cause cascading slowdowns. If you see one that's been sitting there for longer than expected, it's almost certainly a bug in application code — a missing COMMIT , an unhandled e

Building an AI-Powered Content Scanner for Windows: Performance, Multithreading and GPU Acceleration in .NET Building software always looks straightforward from the outside. You load a machine learning model, point it at some images, and display the results. At least that's what I thought when I started building DetectNix Vision , a Windows desktop application that performs local AI-powered image analysis without uploading user data to the cloud. In reality, the project became a deep dive into performance optimization, memory management, multithreading, GPU acceleration, and user experience. This article covers the engineering challenges I encountered and the architectural decisions I made while building the software from the perspective of a senior developer. The Original Goal The initial goal was simple: Scan images stored on a Windows PC Detect potentially explicit or sensitive content Keep all processing local Support both CPU and GPU execution Process large image collections efficiently Remain responsive while scanning Privacy was a major requirement. I didn't want users uploading personal files to third-party services. Everything needed to run locally on the user's machine. That decision immediately influenced every technical choice that followed. Challenge #1: Model Loading Performance One of the first mistakes I made was loading the AI model too frequently. A modern computer vision model can be hundreds of megabytes in size. Loading it repeatedly creates significant startup overhead and quickly destroys performance. My initial implementation worked perfectly during testing because I was only processing a handful of images. Once I started testing larger image collections, the bottleneck became obvious. The Solution I moved to a singleton-style architecture where the model is loaded once during application startup and remains resident in memory. private readonly InferenceSession _session ; public VisionEngine () { _session = CreateSession (); } This reduced in

PostgreSQL Partitioning for Multi-Tenant Audit Logs: Querying 100M Events Without Table Scans I'll be direct: if you're running a SaaS with compliance requirements and your audit_logs table is approaching 50M rows, you're three months away from pain. I've watched audit queries go from 200ms to 8 seconds in production at 2am because someone ran a "give me all logs for tenant X" report. Partitioning isn't optimization theater—it's table-stakes infrastructure. At CitizenApp, we store 9 months of audit logs across 50+ tenants. Without partitioning, a single compliance query would full-table scan 100M+ rows. With it, we hit the same data in <100ms. This post is exactly how we do it. Why Partitioning Matters (The Reality Check) Most developers treat audit_logs like any other table. You add an index on tenant_id and created_at , call it done, and move on. Then your compliance officer runs a query like: SELECT * FROM audit_logs WHERE tenant_id = 'acme-corp' AND created_at >= '2024-01-01' ORDER BY created_at DESC ; At 50M rows, even with a composite index, PostgreSQL has to: Index scan → finds millions of matching rows Random I/O all over the table Spill to disk if sorting is large Hope the OS cache is warm Partitioning solves this by eliminating the data you don't need from day one . Instead of scanning a 100GB table and filtering it down, PostgreSQL can skip entire partitions. A query against January 2024 data simply ignores partitions for February–December. I prefer partitioning because it's native PostgreSQL—no external caching layer, no read replicas, no Redis gymnastics. It's boring infrastructure that works. The Partitioning Strategy: Composite Partitioning (Range + List) I use a two-level partitioning scheme: Range partition by month ( created_at ) — keeps each partition to ~5–10GB List subpartition by tenant — ensures compliance queries are single-partition scans This is deliberately opinionated. You could do range-only, but then a multi-tenant query still scans the

I spent yesterday building purejq , a pure-Python implementation of jq. I expected it to be the slow-but-portable option. Then I benchmarked it against the jq package on PyPI (the C bindings everyone uses to run jq from Python) and got this, on a 100k-object array, in-process: workload purejq jq PyPI (C bindings) field-access stream 9 ms 368 ms filter + count 55 ms 442 ms map + aggregate 18 ms 444 ms group_by 112 ms 704 ms transform + sort 136 ms 899 ms Pure Python, 7-40x faster than the C extension. That number looked wrong to me too, so before publishing anything I made the benchmark script verify every output against the actual jq binary first ( tools/bench.py --verify ), re-ran everything as median-of-7, and gave the bindings their best-case API. The gap is real. Here's why. The serialization tax The C bindings wrap real jq, and real jq only speaks JSON. So every call does this: your dicts -> JSON text -> C parser -> jq evaluates -> JSON text -> dicts That round trip costs about 350-450 ms for 100k small objects on my machine, before any actual filtering happens. You can see it in the numbers: even a trivial field access pays the same ~400 ms floor as a group_by. purejq skips the trip entirely. It compiles the jq program once into Python closures and walks your dicts and lists directly: import purejq prog = purejq . compile ( " group_by(.team) | map({team: .[0].team, n: length}) " ) prog . first ( data ) # operates on your objects, no serialization The lesson generalizes beyond jq: when you embed a C library that has its own data model, the marshaling boundary is often more expensive than the work. An interpreter written in your language gets to skip the boundary, and that can buy back an order of magnitude. Surprise number two: the CLI beats the jq binary on big files This one I really didn't expect. End to end on a 93 MB file (1M objects), parse + filter + output: workload purejq CLI jq 1.8.1 binary single lookup 0.51 s 1.68 s filter + count 1.08 s 1.96 s grou

Earlier parts examined the performance characteristics of sequential and random access under single-threaded execution, and noted in passing the destructive effect of random access on the TLB. This part devotes full attention to the TLB: what it is, why a TLB miss is more severe than a cache miss, why a page table walk constitutes one of the longest dependency chains a CPU can encounter, how huge pages fundamentally alter TLB reach, and where memory-level parallelism falters in the face of TLB misses. Page Boundaries: Where the Prefetcher Halts Part III, in its discussion of prefetchers, noted a hard constraint: a prefetcher must not cross page boundaries on its own authority. The operating system manages virtual memory in units of pages (typically 4 KB, i.e., 64 cache lines). When a program reaches the end of one page and is about to step into the next, the prefetcher cannot proceed. The reason is that the next page may not reside in physical memory (it may have been swapped out to disk), or it may be an entirely invalid virtual address — if the prefetcher were to speculatively initiate an access to the next page, it would trigger a page fault: the OS would have to suspend the process and swap the page in from disk; in the case of an invalid address, the OS would terminate the process outright. From a security standpoint, the prefetcher neither can nor is permitted to autonomously cross page boundaries without TLB approval. Hence a performance brake appears every 4 KB — even when traversing an array sequentially, after every 64 cache line accesses the prefetch pipeline must pause and await confirmation of an address translation. This is not to say that modern CPU prefetchers are completely unable to cross pages. Intel's Next Page Prefetcher and AMD's equivalent mechanism can consult the TLB when approaching a page boundary — if the address mapping for the next page is already registered in the TLB, the prefetcher receives clearance to continue prefetching across th

🎬 This article is a companion to my YouTube video. Watch it here: Introduction In this video we are going to talk about Redis — what it is, what it does, and why it is an important part of my back-end stack. What is Redis? Redis is a free, open-source, in-memory data store. Unlike PostgreSQL which stores data on disk, Redis stores data entirely in memory — in RAM. This makes it extremely fast. Redis can handle millions of operations per second with sub-millisecond response times. Redis is most commonly used as a cache, a session store, a message broker, and a real-time data store. What is Caching? When your application queries a database, that query takes time — it reads from disk, processes the query, and returns the result. If the same query is made thousands of times per second, you are hitting the database thousands of times unnecessarily. Caching solves this by storing the result of a query in memory. The first request hits the database and the result is stored in Redis. Every subsequent request gets the result from Redis — which is in memory and therefore much faster — instead of hitting the database again. Think of it like a shortcut. Instead of driving the long route to the database every time, you take the shortcut through Redis. What Does Redis Do? Caching Store frequently accessed data in memory for fast retrieval. Database query results, API responses, computed values — anything that is expensive to compute and accessed frequently is a good candidate for caching. Session Storage Store user session data in Redis instead of the database. Since sessions are read on every request, having them in memory is significantly faster than a database lookup. Rate Limiting Track how many requests a user or IP address has made in a given time window. Redis's atomic increment operations make it perfect for implementing rate limiting. Message Queues and Pub/Sub Redis supports publish/subscribe messaging and message queues. Applications can publish messages to a channel a

Hey, welcome back. Last time we talked about missing parameterization in test scenarios. Today's mistake is similar in spirit. The test runs. The numbers look great. But what you've built isn't a load test. It's a hammer. ⚠️ The script works. The test is inhuman. Real users don't fire requests like a machine gun. They log in. They pause. They read. They click. They pause again. A typical user journey that takes 60 seconds in real life? Without think time, your script does it in just a few seconds. What this breaks Your throughput numbers are fiction. If users complete journeys 30x faster than reality, your RPS is inflated by 30x. You're not measuring capacity — you're measuring endurance under abuse. You stress the wrong things. Realistic concurrency surfaces real bottlenecks. A firehose of instant requests just overloads your connection pool and calls it a day. Production behaves nothing like your test. Because real users think. Your script didn't. 🛠 The fix Add randomized pauses between steps. Every major tool supports it: JMeter: Gaussian Random Timer, Uniform Random Timer etc. k6: sleep(Math.random() * 5 + 3) Gatling: pause(3.seconds, 8.seconds) Locust: time.sleep(random.uniform(3, 8)) 3–8 seconds between actions is a reasonable starting point. Check your analytics for what real sessions actually look like. Before your next run: Pauses between every major action? Randomized, not fixed? Does the timing feel human? If not — you're not testing load. You're testing collapse. Think time is one piece of the puzzle. But realistic load modeling goes deeper — it's about understanding how real users behave, how to translate that into a load profile, and how to design a test that actually reflects production. That's not something you patch with a timer. It's something you build from the ground up. If you want to understand the full system — from load model design to test execution to results that mean something — that's exactly what Performance Testing Fundamentals course