标签：#ORM

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

Microsoft today released software updates to plug nearly 200 security holes across its Windows operating systems and supported software, a record number of fixes for the company's monthly Patch Tuesday cycle. Nearly three dozen of those bugs earned Microsoft's most dire "critical" rating, and exploit code for at least three of the weaknesses is now publicly available.

I came to programming late — I didn't get into this world until I was past 35, and I'm 62 now, still writing code every day. This is a "build in public" post about a tool I just finished, and I'd genuinely love your feedback. The itch For years I watched infrastructure teams keep their AWS inventory in spreadsheets. It always worked — right up until it didn't. Nobody had time to keep it current, and every single one eventually drifted away from reality. Middleware EOL was the same story: a hand-maintained list, no alerts, no dashboard, quietly going stale. One day I asked the obvious question: we have tfstate, we have boto3 — why are we still doing this by hand? What I built SyncVey is a self-hosted web app that: Inventories your AWS resources into a System → Environment → Asset ledger (EC2, ECS, Lambda, RDS, S3, ALB, VPC, EBS), scanned live via boto3/AssumeRole Detects attribute-level drift between your tfstate and live AWS — including resources someone built by hand in the console that terraform plan never sees Tracks the app/middleware layer per environment and flags end-of-life runtimes The drift piece is the part I care about most. terraform plan only knows about resources Terraform already manages. The thing that actually bites teams is the resource someone spun up by hand in the console — plan is blind to it. SyncVey diffs your tfstate against the live AWS state, so those show up too. The stack (and why) Django + htmx + Postgres — server-rendered, no SPA, no Node build step MIT-licensed, no SaaS, no telemetry One docker compose up and your data stays inside your own infrastructure git clone https://github.com/MR-TABATA/SyncVey cd SyncVey docker compose up I deliberately leaned on htmx because, for a tool someone has to deploy and maintain themselves, "no frontend toolchain" matters more than a fancy client. I'd love your honest take It's AWS-only for now and very much a solo project, so I'm sure there are rough edges. I'm not an AWS specialist — I deliberatel

Netflix engineer Casey Bleifer shares how to achieve rapid, automated code changes across a massive, diverse software fleet. She discusses building an event-driven orchestration platform using composable, Lego-like steps, and explains how Netflix utilizes automated canary validation, compliance checks, and a custom "confidence metric" to eliminate the long tail of manual engineering migrations. By Casey Bleifer

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

The cars are too big to race well, but the competition for pole position is thrilling.

Pinterest introduced MIQPS, a URL normalization system that identifies which query parameters affect page identity using rendered content fingerprints. It reduces duplicate processing across millions of domains by replacing rule-based approaches with offline analysis, anomaly detection, and runtime parameter maps, improving ingestion efficiency and scalability in large-scale content pipelines. By Leela Kumili

HashiCorp has released Terraform 1.15, introducing dynamic module sources, a formal deprecation mechanism for variables and outputs, a new inline type conversion function, type constraints for output blocks, and native Windows ARM64 support. The release addresses several long-standing requests from the Terraform community. By Matt Saunders

A few weeks after switching from Windows to Linux, I noticed something interesting. The hardware had not changed. The processor was the same. The RAM was the same. The SSD was the same. And yet, the laptop felt noticeably faster. Not necessarily because applications were completing tasks dramatically quicker, but because the entire system felt more responsive. Keyboard input felt immediate. Windows opened faster. Terminal commands appeared instantly. The desktop experience felt smoother. This raised a question: How can the same hardware feel different simply because the operating system changed? While I'm still learning, this is the mental model I've built so far. The Hardware Didn't Change Consider a laptop with: AMD Ryzen processor 16 GB DDR5 RAM NVMe SSD Modern integrated graphics When switching operating systems, none of these components change. The CPU does not suddenly become faster. The RAM does not magically increase. The SSD remains identical. From a hardware perspective: ```text id="u3m9xd" Before → Same Hardware After → Same Hardware So the difference must come from somewhere else. --- ## An Operating System Is Not Just a User Interface Many people think of an operating system primarily as the desktop they see. But an operating system does far more than display windows and icons. It manages: * Memory * CPU scheduling * Processes * Storage * Networking * Device drivers * Background services In other words: > The operating system decides how hardware resources are used. Two operating systems can therefore create very different experiences using the same hardware. --- ## Perceived Performance vs Raw Performance One thing I have learned is that performance is not always about benchmarks. A system can have excellent benchmark scores and still feel sluggish. Why? Because users experience responsiveness, not benchmark numbers. Examples include: * How quickly a window opens * How fast a menu appears * How responsive typing feels * How quickly applications launch

If you’ve ever spent hours debugging slow EC2 workloads or getting sticker shock from unexpected EBS IOPS charges, you’ve probably wondered if there’s a better storage option for temporary, high-performance data. AWS EC2 Instance Storage (also called Instance Store) is one of the most underutilized but powerful tools in the EC2 ecosystem—if you know how to use it correctly. This guide breaks down everything you need to know: core concepts, performance optimizations, use cases, limitations, and how it stacks up against EBS. By the end, you’ll be able to cut storage costs, boost workload performance, and avoid costly data loss mistakes. Table of Contents What Exactly Is AWS EC2 Instance Storage? Core Concepts of EC2 Instance Store Key Features That Make Instance Store Stand Out Which EC2 Instance Types Support Instance Store? Deep Dive: NVMe SSD Instance Store Volumes SSD Instance Store Performance Best Practices EC2 Instance Store vs EBS: Head-to-Head Comparison Top Real-World Use Cases for EC2 Instance Store Critical Limitations to Avoid Costly Mistakes Production-Grade Best Practices for Instance Store Root Volume Options: EBS-Backed vs Instance Store-Backed Instances EC2 Instance Store Pricing: No Hidden Costs Conclusion References What Exactly Is AWS EC2 Instance Storage? EC2 Instance Store is temporary block-level storage that is physically attached to the host server running your EC2 instance. Unlike standalone storage services like EBS, EFS, or S3, it is part of the EC2 service itself, with no network overhead between your instance and the storage disks. Its defining trait is its ephemeral nature: data stored on Instance Store only persists for the lifetime of the associated instance. If you stop, hibernate, or terminate your instance, all data on Instance Store volumes is permanently deleted. Core Concepts of EC2 Instance Store Before you start using Instance Store, make sure you understand these foundational rules: Device naming : Instance Store volumes are

Most merchants know they have unused files. Far fewer realize they're accumulating AI-generated media they never intended to keep. There's a problem quietly growing inside thousands of Shopify stores right now. It's not abandoned carts. It's not slow page speeds. It's not even the 400 unused product images you already know you should deal with. It's something newer, and most merchants have no idea it's happening. The Rise of AI-Generated Commerce Content Over the past two years, AI image tools have gone from novelty to routine. Shopify Magic. Canva AI. Midjourney. ChatGPT image generation. Adobe Firefly. Background removers. Lifestyle photo generators. Product shot enhancers. Merchants are using these tools constantly — to mock up new products, test background options, generate seasonal variants, create ad creatives, experiment with lifestyle photography. The workflow feels clean: generate a few options, pick the best one, move on. Here's what's actually happening on the backend. Every time you use Shopify's native AI tools to generate, edit, or enhance an image, Shopify quietly deposits files into your media library. Not just the one you kept. All of them. The rejected generations. The experimental edits. The "let me try one more variant" files. The abandoned attempts from six months ago when you were testing a new product that never launched. Every. Single. One. Most merchants assume the files they don't choose disappear. They don't. The lifecycle looks something like this: ┌─────────────────────┐ │ AI Image Generation │ └──────────┬──────────┘ │ ▼ ┌─────────────────────┐ │ Rejected Variants │ │ • Drafts │ │ • Test Images │ │ • AI Edits │ └──────────┬──────────┘ │ ▼ ┌─────────────────────┐ │ Hidden Media Files │ │ Accumulate Over Time│ └──────────┬──────────┘ │ ▼ ┌─────────────────────┐ │ AI Clutter │ │ Invisible Technical │ │ Debt │ └──────────┬──────────┘ │ ▼ ┌─────────────────────┐ │ Reduced Media │ │ Governance │ │ • More Noise │ │ • Less Visibility │ │ • Hard

The monorepo vs polyrepo argument is old enough that Buildkite was comparing it to the Vim and Emacs wars back in 2024. It should have been settled, or at least gone quiet. Instead, in the space of six months, an AI coding vendor re-litigated it for the agent era, a benchmark firm published PR cycle-time data across hundreds of organisations, and half the platform engineering threads I read found their way back to it. Something pulled the question out of retirement. I think the something is worth naming, because it is not really about repositories at all. I maintain a product whose entire reason to exist is that most organisations run polyrepos, so I want to be upfront about where I sit before arguing anything. Riftmap parses cross-repo dependencies. If everyone migrated to a monorepo tomorrow, a good part of my roadmap would evaporate. Read what follows with that in mind, and check the sources, all of which are linked. With that declared: I think both camps in this debate are arguing about a proxy. The real variable underneath, the one that decides whether your team ships confidently or plays dependency archaeology at 2am, is something the standard pros-and-cons lists never name. This post walks the honest trade-offs first, because they are real and you deserve a straight answer to the question you searched for. Then it gets to the variable. What each side buys you A monorepo is one repository holding many projects. A polyrepo (or multi-repo) setup gives each project, service, or module its own repository. Both are proven at every scale that matters: Google and Meta run famous monorepos, Amazon and Netflix run famous polyrepos, and none of them are wrong. The monorepo's case The strongest monorepo argument has always been atomic cross-project change. Uber's iOS team moved to a monorepo largely for this: when an API contract and all of its clients live in one repo, a breaking change is one commit, one review, one revert path. No choreographed pull requests across si

SQL tuning is the process of making a database query run faster and cheaper — cutting response time while minimizing the system resources it burns. Here's the playbook I actually use, from "this query is slow" to "this query is fixed," with the traps that bite people in the middle. The loop Tuning is iterative. The shape is always the same: Identify the problem. Find the slow query (logs, profiler, or user feedback) and measure a baseline — execution time and resource usage. You can't claim an improvement you didn't measure. Analyze & rewrite. Review the SQL for redundant joins, unnecessary work, and complex subqueries. Tighten the WHERE , select only the columns you need, convert subqueries to joins where it helps. Read the execution plan. Understand how the engine actually runs the query; find inefficient join orders and needless full scans. Revisit indexes. Evaluate whether existing indexes help; add or restructure as needed. Consider schema changes. If a column is updated so often that indexing it hurts, split it out. Sometimes the model is the bottleneck. Tune settings/hardware if it comes to that. Re-test and repeat. Apply changes, re-check the plan, confirm the gain, monitor. Reading an execution plan The execution plan shows how the DB will run your query — table scans, index access, join methods. Read it well and you can pinpoint where the time goes. Most engines expose it: EXPLAIN (MySQL/PostgreSQL), EXPLAIN PLAN FOR (Oracle), SET SHOWPLAN_ALL ON (SQL Server). Operators to know: Full Table Scan — reads every row. Happens when there's no suitable index, or the query can't use one. Index Scan — scans via an index; usually cheaper than a table scan. Index Seek — jumps to specific key values; very efficient, reads only the rows it needs. Nested Loops / Hash Join / Merge Join — the three ways to join two tables (more below). Sort — orders data; excessive sorting is a common performance drag. Three numbers that matter: Cost — estimated resources a step will cons

The IaC landscape split into two philosophies about a decade ago and hasn't fully resolved the argument since. On one side: declarative configuration languages designed specifically for infrastructure (Terraform HCL, CloudFormation YAML, Bicep). On the other: general-purpose programming languages brought to infrastructure (AWS CDK, Pulumi). Both approaches have won in production at major organizations. Neither is clearly superior. This comparison covers Terraform, AWS CDK, and Pulumi in depth — how they work, where they excel, where they struggle, and which makes sense for different team situations. It isn't a beginner introduction to any of these tools; if you're choosing between them for a real project, this assumes you've at least skimmed each one. The core philosophical difference Terraform's HCL is a purpose-built configuration language. It's not Turing-complete (no arbitrary loops, no recursion, limited conditionals). This is by design: HashiCorp's position is that infrastructure definitions should be readable, predictable, and safe to generate tooling around. When you read a .tf file, you can understand what it creates without executing anything. CDK and Pulumi take the opposite position: the limitations of configuration languages are a tax on productive engineers. Why invent a domain-specific language when TypeScript already exists? Real programming languages have proper abstractions, test frameworks, package managers, IDE support, and a billion engineers who already know them. Infrastructure should be no different from application code. Both positions have merit. The choice between them often comes down to who's writing the infrastructure more than which approach is technically superior. Terraform Terraform is the default choice for infrastructure-as-code in 2026. It works with every major cloud provider and hundreds of minor ones. The Terraform Registry has thousands of modules — reusable packages for common patterns like VPCs, EKS clusters, and RDS databa

Alzheimer's disease affects over 55 million people worldwide, yet the precise molecular changes happening inside individual brain cells remain poorly understood. I wanted to dig into that question - not at the tissue level, but at single-cell resolution. So I built a full scRNA-seq analysis pipeline in Python using Scanpy, working with a publicly available dataset of 63,608 nuclei from human prefrontal cortex tissue (sourced from CZ CELLxGENE). The donors spanned three Braak stages: 0 (cognitively normal), 2 (early Alzheimer's), and 6 (severe Alzheimer's). Here's what I found and how I found it. The Dataset The data came from a study on the molecular characterisation of selectively vulnerable neurons in AD. It covers the superior frontal gyrus, a prefrontal region known to be hit hard by neurodegeneration - and includes seven major brain cell types: Glutamatergic neurons GABAergic neurons Oligodendrocytes OPCs (oligodendrocyte precursor cells) Astrocytes Microglia Endothelial cells 31,997 genes. 63,608 cells. Three disease stages. A lot to work with. The Pipeline 1. Quality Control No dataset is clean out of the box. I filtered cells to keep only those with between 200 and 6,000 detected genes, and excluded anything with more than 20% mitochondrial gene content (high mitochondrial reads usually signal a dying or damaged cell). This removed around 2,809 low-quality cells. 2. Normalisation Library sizes were normalised to 10,000 counts per cell, followed by log1p transformation, standard practice that makes cells comparable regardless of how deeply they were sequenced. I then identified 5,607 highly variable genes to focus the downstream analysis. 3. Dimensionality Reduction PCA (50 components) → neighbourhood graph (10 neighbours, 20 PCs) → UMAP embedding. The UMAP is where the biology starts to become visible. All seven cell types separated into distinct clusters, with clear separation between neuronal subtypes and glial populations. 4. Differential Expression For t

Claude Cowork est sorti en 2026 et le distinguer des agents cloud classiques change tout pour les equipes techniques. Deux modeles, deux philosophies Un agent cloud (ChatGPT Operator, Mistral Agents, Gemini pour Workspace) fait des appels API vers des serveurs distants. Vos donnees quittent votre machine. La session prend fin quand vous fermez le navigateur. Claude Cowork fonctionne differemment : il tourne sur votre Mac, lit votre systeme de fichiers en direct, execute des bash commands, et continue sa tache quand vous fermez le laptop. Ce que cela change pour les equipes tech Contexte reel. Cowork peut lire vos logs, vos configs, vos repos locaux directement, sans copier-coller. Execution longue distance. Vous lancez un refactoring sur 40 fichiers, vous allez en reunion. La tache continue. Impossible avec un chatbot classique. Isolation des donnees. Pour les equipes qui travaillent sur des donnees sensibles (sante, legal, finance), garder les donnees en local repond a une contrainte non negociable. Les limites a connaitre Cowork necessite un Mac recent (Apple Silicon recommande). Le context window est partage entre linterface et les fichiers lus. Pour des taches qui necessitent une recherche web temps reel, un agent cloud reste complementaire. Pattern que je recommande aux equipes Dans les formations que janime pour des equipes de 10 a 100 personnes, on structure generalement comme ca : Agent local (Cowork) pour tout ce qui touche le codebase, les fichiers, les automatisations internes. Agent cloud pour les recherches, les comparaisons marche, les taches qui ont besoin dun acces web. Un workflow clair pour decider lequel utiliser selon la nature de la tache. Le point cle : ne pas les traiter comme interchangeables. Ce sont deux outils avec des forces differentes. Ce que les chiffres montrent Dans les equipes que jai accompagnees sur 18 mois, celles qui ont adopte ce pattern produisent en moyenne 40 % de code de configuration en moins de temps, avec moins de bugs l

It's important to monitor Dataform - jobs executed by Dataform can be the primary source of BigQuery costs in a modern data platform. Forgetting to incrementalise a table, using a table instead of a view in the wrong place or performing complex window functions on a large table can all incur large costs and long run times. Using the WorkflowInvocationAction for each job we can extract its BigQuery Job ID, then extract key metadata for each BigQuery job by querying INFORMATION_SCHEMA.JOBS_BY_PROJECT , before writing the output back to BigQuery so that it can be analysed (maybe even by transforming it in Dataform). from google.cloud import dataform_v1 from google.cloud import bigquery from datetime import datetime # ------------------------------------------------------------ # CONFIG # ------------------------------------------------------------ PROJECT_ID = " my-project " REGION = " europe-west2 " REPOSITORY_ID = " analytics " WORKFLOW_INVOCATION_ID = " 123456789 " BQ_REGION = " region-europe-west2 " OUTPUT_TABLE = " my-project.raw_dataform_monitoring.raw_dataform_bigquery_metrics " # ------------------------------------------------------------ # CLIENTS # ------------------------------------------------------------ dataform = dataform_v1 . DataformClient () bq = bigquery . Client ( project = PROJECT_ID ) repository = dataform . repository_path ( PROJECT_ID , REGION , REPOSITORY_ID ) invocation_name = f " { repository } /workflowInvocations/ { WORKFLOW_INVOCATION_ID } " # ------------------------------------------------------------ # 1. GET WORKFLOW INVOCATION ACTIONS → EXTRACT JOB IDS # ------------------------------------------------------------ job_ids = set () actions = dataform . list_workflow_invocation_actions ( parent = invocation_name ) for action in actions : # only BigQuery actions contain job metadata if hasattr ( action , " bigquery_action " ) and action . bigquery_action : if action . bigquery_action . job_id : job_ids . add ( action . bigquery_action

Published on : 2026-06-06 Reading time : 6 min Tags : #python #async #performance #optimization The Problem: Fake Async The supabase-async library claimed to be async but actually wrapped synchronous calls with ThreadPoolExecutor: # ❌ Fake async (old code) class SupabaseAsync : def __init__ ( self ): self . _executor = ThreadPoolExecutor ( max_workers = 3 ) async def select ( self , table : str ): loop = asyncio . get_event_loop () r = await loop . run_in_executor ( self . _executor , lambda : requests . get ( url ) # Sync call wrapped as async ) return r . json () Problems : Max 3 concurrent requests (not scalable) Thread overhead per request High memory usage No connection pooling Solution: httpx AsyncClient Use true async HTTP with httpx: # ✅ Real async (new code) import httpx class SupabaseAsync : def __init__ ( self ): self . _client : Optional [ httpx . AsyncClient ] = None async def _get_client ( self ) -> httpx . AsyncClient : if self . _client is None : self . _client = httpx . AsyncClient ( headers = self . _headers , timeout = 30 , limits = httpx . Limits ( max_connections = 10 ) ) return self . _client async def select ( self , table : str ): client = await self . _get_client () r = await client . get ( f " { self . _base } / { table } " ) r . raise_for_status () return r . json () Performance Gains Metric ThreadPoolExecutor(3) httpx(10) Max concurrent 3 requests 10 requests Avg response 450ms 150ms Memory usage 250MB 180MB Throughput 6.7 req/s 20 req/s Real benchmark : 100 concurrent requests ThreadPoolExecutor: 15 seconds httpx AsyncClient: 5 seconds 3x faster ⚡ Migration Steps 1. Client Initialization with Lazy Loading async def _get_client ( self ) -> httpx . AsyncClient : if self . _client is None : self . _client = httpx . AsyncClient ( headers = self . _headers , timeout = 30 , limits = httpx . Limits ( max_connections = 10 , max_keepalive_connections = 5 ) ) return self . _client 2. HTTP Methods (GET, POST, etc.) async def _request ( self , metho

Published on : 2026-06-06 Reading time : 6 min Tags : #python #async #performance #optimization 문제: 거짓 비동기 supabase-async 라이브러리는 이름은 async이지만, 실제로는 ThreadPoolExecutor로 동기 호출을 래핑하고 있었습니다. # ❌ 거짓 비동기 (기존 코드) class SupabaseAsync : def __init__ ( self ): self . _executor = ThreadPoolExecutor ( max_workers = 3 ) async def select ( self , table : str ): loop = asyncio . get_event_loop () r = await loop . run_in_executor ( self . _executor , lambda : requests . get ( url ) # 동기 호출을 async로 포장 ) return r . json () 문제점 : 최대 3개 동시 요청만 가능 (동시성 부족) 스레드 오버헤드 (각 요청마다 스레드 생성) 높은 메모리 사용량 해결책: httpx AsyncClient 진정한 비동기 HTTP 클라이언트인 httpx를 사용합니다. # ✅ 진정한 비동기 (수정된 코드) import httpx class SupabaseAsync : def __init__ ( self ): self . _client : Optional [ httpx . AsyncClient ] = None async def _get_client ( self ) -> httpx . AsyncClient : if self . _client is None : self . _client = httpx . AsyncClient ( headers = self . _headers , timeout = 30 , limits = httpx . Limits ( max_connections = 10 ) ) return self . _client async def select ( self , table : str ): client = await self . _get_client () r = await client . get ( f " { self . _base } / { table } " ) r . raise_for_status () return r . json () 성능 개선 동시성 비교 지표 ThreadPoolExecutor(3) httpx(10) 최대 동시 요청 3개 10개 평균 응답 시간 450ms 150ms 메모리 사용량 250MB 180MB 초당 처리량 6.7 req/s 20 req/s 벤치마크 # 100개 동시 요청 처리 시간 ThreadPoolExecutor : 15 초 httpx AsyncClient : 5 초 → 3 배 빠름 마이그레이션 단계 1. 클라이언트 초기화 async def _get_client ( self ) -> httpx . AsyncClient : if self . _client is None : self . _client = httpx . AsyncClient ( headers = self . _headers , timeout = 30 , limits = httpx . Limits ( max_connections = 10 , max_keepalive_connections = 5 ) ) return self . _client 2. 요청 메서드 async def _request ( self , method : str , url : str , ** kwargs ): client = await self . _get_client () if method == " GET " : return await client . get ( url , ** kwargs ) elif method == " POST " : return await client . post ( url , ** kwargs ) # ... 3. Context Manager 지원 async def clos