用asyncio重构Flask接口，QPS从320提升到2100的优化记录
一个查询用户订单详情的接口，原本用Flask同步实现，压测QPS只有320，P99延迟高达1.2s。排查发现瓶颈在于接口内部串行调用了3个下游HTTP服务。改用FastAPI + asyncio并发编排后，QPS提升到2100，P99降到180ms。本文完整记录改造前后的代码、压测数据、以及踩过的坑，包括aiohttp连接池配置、asyncio.gather异常处理、以及event loop被阻塞
猞猁喜欢开源日记
Lv.1擅长围观技术变化，也愿意亲手验证。关注开源技术，主要分享开发效率提升、性能优化和日常踩坑；更关注能够真正落地的方法。技术会变化，解决问题的方法值得长期积累。
7文章
0粉丝
0关注
1获赞
最新文章
Prompt Engineering实验：同一文本分类任务下6种提示词的Token消耗与输出质量对比
本文用一个真实的中文情感分类任务（1000条外卖评论，3分类），对6种不同Prompt设计做了完整对比实验。模型选用gpt-4o-mini(2024-07-18)与qwen-plus(2024-09-19)，温度统一设为0。实验记录了每种Prompt的输入Token、输出Token、准确率、格式合规率和单条成本。结果发现：带Few-shot的Prompt准确率从78.3%提升到91.6%，但Tok
Docker Compose编排多服务容器化部署与健康检查依赖顺序配置
一个真实项目从单机 `docker run` 迁移到 Docker Compose 的完整过程。项目包含 Nginx、Spring Boot API、MySQL 8.0、Redis 7.2 四个服务，最初因为启动顺序问题导致 API 容器反复重启 17 次才成功。本文给出完整的 `docker-compose.yml`，包含自定义 bridge 网络、命名卷挂载、`healthcheck` 健康检
Milvus与Qdrant双雄对决：电商语义检索场景实测选型
在商品标题向量检索场景下，我用真实数据对比Milvus 2.4.1与Qdrant 1.9.0。部署上Milvus用Helm三节点集群，Qdrant用Docker单节点+WAL。实测300万条768维向量，Qdrant纯查询P99 8ms优于Milvus的15ms，但Milvus在混合过滤（标签+向量）场景下召回率稳定在0.93，Qdrant降至0.81。资源占用上Qdrant内存峰值低37%，但M
asyncio重构Flask接口，QPS从187到1520的并发改造实录
在一次电商订单导出服务中，我遇到CPU空闲但接口超时的诡异场景。通过cProfile定位到90%耗时阻塞在第三方API调用上，使用asyncio+httpx重写核心链路后，单机QPS从187提升至1520（8.1倍），P99延迟从2.3s降至340ms。本文将完整记录这次改造过程，包括asyncio.Semaphore限流的正确姿势、与Flask同步生态的集成方案，以及协程池+线程池混合调度的性能
React 19与Vue 3.5下从Context到Zustand/Pinia的迁移实录与性能对比
接手一个维护了两年的中后台项目，组件树深度超过8层，Context频繁触发全树渲染，导致列表页输入卡顿（实测输入延迟从180ms飙升至600ms）。本文记录从React Context（或Vue Provide/Inject）迁移至Zustand 4.5（或Pinia 2.1）的完整过程，包含方案选型对比、分步迁移策略（按模块灰度切换）、核心代码改造示例，以及迁移前后的Performance面板数
React 19与Vue 3.5跨框架状态管理迁移：从Prop Drilling到Pinia/Zustand的工程化改造
在维护一个拥有87个路由页面、月活30万的中后台项目时，我们遇到了组件树层级超过12层的状态传递地狱。本文记录了从原生Context/Props迁移到Zustand v4.5.5（React 19.0.0）与Pinia v2.2.6（Vue 3.5.12）的全过程。通过具体对比三种方案的渲染性能（Context导致重渲染次数增加340%，迁移后FCP提升21.7%），并给出可复制的迁移步骤与性能优