一行同步代码拖垮asyncio：语音AI p95延迟飙至11.4秒

一个语音面试服务，单人测试时响应0.9秒，8人并发时最后一个用户等了11.4秒，听起来像坏了。模型、网络、语音供应商全都正常。问题出在一行代码：在async def里调用了同步的client = Anthropic()。

这个bug的作者是语音面试平台Preterview的开发者。他花了整整两天排查错误方向，最终通过事件循环延迟监控定位到根因。整个过程有完整的数据记录，对任何写async Python的开发者都有参考价值。

单用户测试为什么看不出来

阻塞事件循环在没有其他协程等待时，代价为零。单用户场景下，一个2.3秒的阻塞调用看起来就像一个2.3秒的LLM调用。没有其他会话排在后面，一切正常。

作者的本地测试、staging环境和演示通话都只有一个用户——他自己。所有测量结果都是0.9秒首音频延迟。于是直接上线了。

生产环境的表现

最初的投诉是"面试官卡了几秒"和"音频断断续续"。不是每个会话都这样，只在一天中的某些时段出现。

作者依次排查了三个方向：语音转文字供应商在高峰期变慢（换了区域，没变化）；TTS分块太小（调大后更糟）；LLM变慢（但Claude每次调用的耗时从凌晨3点到晚上8点完全平稳）。

第三条线索才是关键。模型耗时没有变化，但用户等待时间在高峰期大幅增加。多出来的时间消耗在他自己的进程内部。

如何检测被阻塞的事件循环

开启asyncio调试模式并降低慢回调阈值，事件循环会记录每一个超过阈值的步骤及其对应的任务：

import asyncio
import logging

logging.basicConfig(level=logging.WARNING)

async def on_startup():
    loop = asyncio.get_running_loop()
    loop.set_debug(True)
    loop.slow_callback_duration = 0.1

在staging环境的负载回放测试中，日志里充满了类似Task-412 coro=<session_turn() running at app/session.py:88>> took 2.312 seconds的记录。

调试模式有额外开销，不适合生产环境。作者改用了一个10行的延迟监控器——每100毫秒睡一次，检查醒来晚了多少。如果事件循环空闲，它会准时醒来；如果被占用，醒来的延迟就反映了阻塞时长。

async def loop_lag_monitor(interval: float = 0.1, warn_ms: float = 50):
    loop = asyncio.get_running_loop()
    while True:
        start = loop.time()
        await asyncio.sleep(interval)
        lag_ms = (loop.time() - start - interval) * 1000
        if lag_ms > warn_ms:
            log.warning("event loop lag %.0f ms", lag_ms)

一周的生产日志中，这个监控器记录了1412次超过100ms的警告。与staging的调试追踪匹配后，来源分布如下：

阻塞来源	警告次数	占比
同步Anthropic客户端调用	868	61%
pypdf简历解析	325	23%
同步requests.post webhook + time.sleep重试	219	16%

最长的一次单次阻塞达7.9秒：pypdf处理一份14页简历时，服务器上所有进行中的面试全部沉默。

慢回调追踪与循环延迟监控的区别

asyncio的调试模式在每个事件循环步骤（包括任务的一步执行、定时器回调、socket就绪处理）前后记录时间戳，若耗时超过loop.slow_callback_duration就输出警告，并附带正在运行的协程名与源码位置，这是定位阻塞点的直接证据。

而延迟监控器采用不同原理：它不侵入事件循环内部，而是用一个周期性asyncio.sleep任务充当心跳。如果循环空闲，该协程会准时在100毫秒后醒来；若某个同步任务占用了循环，心跳就会被顺延，醒来时间差减去预期间隔即为被阻塞时长。

两种手段互补。调试模式给出谁在阻塞的精确调用栈，但开销较大，只适合staging；延迟监控器给出阻塞了多久的生产级指标，开销几乎为零，可长期运行。本文正是先用调试模式在staging定位来源分布，再用延迟监控器在生产环境持续统计次数，两者数据互相印证，形成了完整的排查链条。

同步客户端为什么阻塞一切

async def只在await处让出控制权。同步网络调用没有await，事件循环会一直卡到socket读取返回。作者的代码看起来没什么问题：

client = Anthropic()  # sync client

async def session_turn(ws, history):
    with client.messages.stream(model=MODEL, max_tokens=400, messages=history) as stream:
        for text in stream.text_stream:      # blocks the loop waiting for each chunk
            await ws.send_text(text)         # yields, but only for a moment

await ws.send_text让它看起来像是异步的。但for text in stream.text_stream是一个同步迭代器，在每次分块之间都在做阻塞socket读取。实际上，整个生成过程中事件循环都是冻结的，除了每次发送时几微秒的让出。

其他所有会话的音频帧、TTS分块和心跳都在排队等待。8个人同时在回答时，最后一个人要等前面7次生成完成才开始自己的。

事件循环与协作式并发

Python的asyncio采用单线程协作式并发模型。所有协程共享同一个线程上的唯一事件循环，任意时刻只能有一个协程运行。协程只有在遇到await表达式时才主动把控制权交还给事件循环，由其调度下一个就绪任务。

关键在于，await只是一个让出点，它本身不能让阻塞代码变异步。如果await的底层操作仍然是同步阻塞的，例如一次同步socket读取，那么事件循环在它返回前无法运行其他任何任务。许多开发者误以为写成async def就自动获得并发能力，实际上async def只定义了一个协程工厂，函数体内的同步代码依旧逐行独占线程执行。这就是为什么同步的socket读取、requests调用、time.sleep会成为异步程序的杀手：它们不交出控制权，导致音频帧、心跳、TTS分块等所有排队中的协程被同时冻结。理解这一点，才能明白为什么一行同步客户端代码会让服务器上所有用户的延迟串联累加。

并发条件下的恶化曲线

作者写了一个负载测试，回放录音答案并测量首音频时间（TTFA）——从用户停止说话到第一个TTS字节发出。以下是每档200轮对话的p95数据：

并发会话数	同步客户端	to_thread中的同步客户端	AsyncAnthropic
1	0.9s	0.9s	0.9s
4	5.2s	1.0s	0.9s
8	11.4s	3.4s	1.0s

asyncio.to_thread够用吗

只在一定范围内够用。asyncio.to_thread在事件循环的默认ThreadPoolExecutor上运行调用，Python 3.8起默认工作线程数为min(32, os.cpu_count() + 4)。在2-vCPU机器上是6个线程。

作者的第一反应是把同步stream包在to_thread里，4个会话时看起来解决了。但到8个会话时，两个对话在executor队列中等待空闲线程，p95升到3.4秒。事件循环不再冻结，但出现了新瓶颈：线程池。

可以扩大线程池，但这样做意味着每个进行中的LLM调用都要占一个线程，只是为了让一个不为你的运行时设计的客户端继续工作。SDK已经提供了异步客户端，直接用就好。

线程池、GIL与并发瓶颈

asyncio.to_thread把同步函数扔到默认的ThreadPoolExecutor上执行，从而把阻塞从事件循环线程转移出去，恢复循环响应。但Python的全局解释器锁GIL意味着同一时刻只有一个线程能执行Python字节码。对于网络I/O这类会在等待时释放GIL的操作，多线程确实能并发等待；而对于CPU密集的纯Python任务如pypdf解析，线程之间会反复争抢GIL，并发收益很小，甚至因线程切换而变慢。

此外，默认线程数为min(32, os.cpu_count() + 4)，在2-vCPU机器上只有6个。一旦并发数超过线程数，新任务就会在executor队列里等待空闲线程，于是事件循环不再冻结，但任务开始排队，延迟出现新的恶化曲线。因此正确的决策是分类处理：I/O等待型同步调用优先用官方异步客户端；确实无法异步且CPU密集的任务放入ProcessPoolExecutor以绕过GIL；只有少量偶发的同步阻塞才适合to_thread作为过渡方案。

正确的修复方式

使用AsyncAnthropic并用async for迭代流，这样每次等待下一个分块都是真正的await：

from anthropic import AsyncAnthropic

client = AsyncAnthropic()

async def session_turn(ws, history):
    async with client.messages.stream(model=MODEL, max_tokens=400, messages=history) as stream:
        async for text in stream.text_stream:
            await ws.send_text(text)

三个单词的改动，把8会话的p95从11.4秒降到1.0秒。

另外39%的警告需要不同的修复方式。pypdf简历解析是CPU密集的纯Python代码，移到to_thread能保持事件循环大部分响应，但仍会与循环线程竞争GIL。作者最终将其移到ProcessPoolExecutor(max_workers=2)配合loop.run_in_executor。requests.post换成httpx.AsyncClient。重试helper里的time.sleep(2)改成await asyncio.sleep(2)——它藏在一个"utils"文件里，每次重试都冻结服务器整整两秒。

修复后的一周，延迟监控器只记录了9次超过100ms的警告，全部低于180ms，全部来自垃圾回收暂停。从1412次降到了9次。

防止复发

作者总结了三条措施：

保持生产环境的延迟监控，p99循环延迟超过100ms时告警。代码只有10行，开销几乎为零。

负载测试要测并发而非只看延迟。单会话测试根本抓不到这类bug。作者的CI现在跑1、4、8会话的回放测试，如果p95在8会话时超过1会话的1.5倍就失败。

在异步代码路径中搜索常见嫌疑对象：Anthropic(、OpenAI(、requests.、time.sleep以及同步文件或PDF解析。一条lint规则在包含大量async def的模块中标记同步客户端，又在上线前拦住了两个问题。

作者最后写道：在async Python中，最慢的阻塞调用决定了机器上每个用户的延迟，而不仅仅是触发它的那个用户。