性能 | Jeanphilo Blog

缓存大小如何确定：命中率、成本与稳定性

副标题 / 摘要缓存大小不是拍脑袋，而是命中率、成本与稳定性之间的平衡。本文给出确定缓存大小的工程方法。目标读者负责缓存系统和性能优化的工程师做容量规划与成本控制的团队需要提升命中率与稳定性的开发者背景 / 动机缓存太小会导致频繁穿透，太大则成本高且失效风险增加。正确做法是用数据驱动的方式确定缓存大小。核心概念命中率（Hit Rate）：缓存命中 / 总请求工作集（Working Set）：短期内频繁访问的数据集合淘汰策略：LRU/LFU 等成本曲线：边际命中率收益逐渐降低实践指南 / 步骤采集访问分布（热度、访问频率）估算工作集大小用不同容量做离线回放评估命中率与成本曲线预留安全余量（波峰期、突发流量）可运行示例下面模拟不同缓存容量的命中率： from collections import OrderedDict def lru_hit_rate(requests, capacity): cache = OrderedDict() hits = 0 for key in requests: if key in cache: hits += 1 cache.move_to_end(key) else: if len(cache) >= capacity: cache.popitem(last=False) cache[key] = True return hits / len(requests) if __name__ == "__main__": reqs = [1,2,3,1,2,4,1,2,3,5,1,2,3,4] for cap in [1, 2, 3, 4]: print(cap, lru_hit_rate(reqs, cap)) 解释与原理缓存大小的收益是递减的：容量越大，新增命中率提升越小。因此需要找到“边际收益开始下降”的拐点，而不是盲目扩容。 ...

什么是 O/R 阻抗失衡：对象世界与关系模型的冲突

副标题 / 摘要 O/R 阻抗失衡指对象模型与关系模型的结构和语义不一致，导致映射复杂、性能问题和维护成本上升。本文给出可落地的缓解策略。目标读者使用 ORM 的后端工程师负责数据建模与性能优化的开发者想理解“为什么 ORM 不是银弹”的团队负责人背景 / 动机对象世界是图结构（引用、继承、聚合），关系世界是表结构（行、列、外键）。两者语义不同，映射时必然损失与扭曲，这就是 O/R 阻抗失衡。核心概念对象图：一对多、多对多关系关系模型：表与外键，依赖 JOIN 映射成本：查询复杂、N+1、延迟加载等实践指南 / 步骤先设计数据访问模式，再设计模型结构为读与写设计不同模型（CQRS 思路）控制对象图深度，避免自动级联查询使用 DTO 作为边界，减少 ORM 泄漏对关键路径手写 SQL 可运行示例下面示例展示对象与关系的差异： import sqlite3 conn = sqlite3.connect(":memory:") cur = conn.cursor() cur.execute("CREATE TABLE user(id INTEGER PRIMARY KEY, name TEXT)") cur.execute("CREATE TABLE orders(id INTEGER PRIMARY KEY, user_id INTEGER, amount INTEGER)") cur.execute("INSERT INTO user VALUES (1, 'Alice')") cur.executemany("INSERT INTO orders VALUES (?, ?, ?)", [(1, 1, 100), (2, 1, 200)]) cur.execute("SELECT u.name, o.amount FROM user u JOIN orders o ON u.id = o.user_id") print(cur.fetchall()) 解释与原理对象模型喜欢“引用”和“聚合”，而关系模型喜欢“表”和“JOIN”。 ORM 需要在两种语义之间做折中，这就产生了性能与复杂度问题。 ...

什么是流式处理（Streaming）：概念与实现方式

副标题 / 摘要流式处理的核心是“边到边算”，避免一次性加载全部数据。本文解释流的概念、适用场景与实现方式。目标读者需要处理大数据或实时数据的工程师想理解流式模型的开发者对性能优化有兴趣的团队背景 / 动机在数据量大或实时性要求高的场景中，一次性加载全部数据会导致内存浪费与延迟。流式处理通过“逐条处理”降低内存占用与延迟。核心概念流（Stream）：数据项按时间或顺序到达管道（Pipeline）：处理步骤串联惰性计算：只有需要时才计算下一项实践指南 / 步骤把数据源转换为迭代器/生成器用管道组合处理步骤避免全量加载，只保留必要状态为每一步设定可观测指标可运行示例 def source(): for i in range(1, 11): yield i def filter_even(stream): for x in stream: if x % 2 == 0: yield x def map_square(stream): for x in stream: yield x * x def sink(stream): for x in stream: print(x) if __name__ == "__main__": stream = source() stream = filter_even(stream) stream = map_square(stream) sink(stream) 解释与原理流式模型通过“惰性迭代”把计算拆成小块。这样既降低了内存占用，也能更快得到部分结果。 ...

什么是实时系统：与普通系统的关键区别

副标题 / 摘要实时系统的核心不是“快”，而是“可预测”。本文解释实时系统与普通系统的差异，并给出工程落地要点。目标读者做嵌入式、自动控制、工业系统的工程师需要理解时限约束的后端开发者想区分“高性能”与“实时性”的技术负责人背景 / 动机很多系统不只要求快，还要求“按时”。比如刹车控制、心电监测、工业自动化等，错过时限比“慢一点”更危险。核心概念硬实时（Hard RT）：错过时限等同失败软实时（Soft RT）：偶尔错过仍可接受确定性（Determinism）：执行时间可预测时限（Deadline）：任务必须完成的时间点实践指南 / 步骤定义时限与容忍度（硬实时/软实时）测量最坏情况执行时间（WCET）选择合适调度策略（如固定优先级）限制不可预测行为（GC、动态分配、锁竞争）建立监控与超时策略可运行示例下面示例用简单的“任务+时限”判断是否满足实时要求： from typing import List, Tuple def is_schedulable(tasks: List[Tuple[int, int]]) -> bool: # (runtime, deadline) time = 0 for runtime, deadline in tasks: time += runtime if time > deadline: return False return True if __name__ == "__main__": print(is_schedulable([(2, 3), (1, 5), (2, 7)])) # True print(is_schedulable([(2, 3), (3, 4)])) # False 解释与原理普通系统关注平均吞吐和响应时间，而实时系统关注“最坏情况”。只要存在无法预测的延迟（GC 停顿、锁竞争、I/O 抖动），就会破坏实时性。 ...

为什么打开 TCP 套接字开销大：握手、状态与系统成本

副标题 / 摘要 TCP 连接不是一次函数调用，而是一组协议状态机与内核资源分配。本文解释开销来源，并给出工程上的优化路径。目标读者负责网络服务优化的后端工程师想理解连接成本的系统开发者需要排查连接耗时的运维与 SRE 背景 / 动机在高并发系统里，“频繁建连”常常成为性能瓶颈。理解 TCP 连接开销来源，才能知道何时该用连接池、何时该复用、何时该改协议。核心概念三次握手：SYN/SYN-ACK/ACK 内核状态：连接表、套接字缓冲区、TCP 状态机慢启动：初始窗口小、吞吐从低到高系统调用成本：socket/connect/accept 带来上下文切换实践指南 / 步骤优先复用连接（HTTP keep-alive / 连接池）减少短连接，批量或长连接替代降低握手成本（TLS session resumption）调优内核参数（连接队列、端口范围）监控连接层指标（SYN 重传、TIME_WAIT）可运行示例下面脚本在本机测量多次建连成本： import socket import threading import time def server(port_holder, ready, n): s = socket.socket() s.bind(("127.0.0.1", 0)) port_holder.append(s.getsockname()[1]) s.listen() ready.set() for _ in range(n): conn, _ = s.accept() conn.close() s.close() def measure(n=200): port_holder = [] ready = threading.Event() t = threading.Thread(target=server, args=(port_holder, ready, n), daemon=True) t.start() ready.wait() port = port_holder[0] start = time.perf_counter() for _ in range(n): c = socket.create_connection(("127.0.0.1", port)) c.close() elapsed = time.perf_counter() - start print(f"{n} connections: {elapsed:.3f}s") if __name__ == "__main__": measure() 解释与原理 TCP 连接要维护状态机、缓冲区、窗口、重传计时器。每次建连都需要三次握手与内核资源分配，还会触发慢启动，吞吐无法立即拉满。 ...

CSR vs SSR：取舍、性能指标与落地路径

副标题 / 摘要 CSR 与 SSR 的选择不是二选一，而是围绕性能、SEO、复杂度的权衡。本文给出可操作的决策路径与示例。目标读者负责前端架构选型的工程师需要改善首屏体验与 SEO 的团队希望理解 TTFB/TTI 的开发者背景 / 动机 CSR（客户端渲染）强调前端灵活与交互性，SSR（服务端渲染）强调首屏体验与 SEO。很多项目因为选型不当，出现首屏慢、SEO 差或部署复杂度过高的问题。核心概念 TTFB：首字节时间，越小越好 TTI：可交互时间 Hydration：SSR 之后在客户端接管交互 SEO：搜索引擎对 HTML 内容的可见性实践指南 / 步骤先看内容属性：是否依赖 SEO、是否内容密集评估交互复杂度：高度交互通常偏向 CSR 或 SSR+Hydration 关注性能指标：TTFB、FCP、TTI、CLS 考虑部署成本：SSR 需要服务器渲染能力混合策略：关键页 SSR，其余 CSR 或 SSG 可运行示例下面用一个最小 Python 服务演示 SSR 和 CSR 的差异： from http.server import BaseHTTPRequestHandler, HTTPServer import json import time class Handler(BaseHTTPRequestHandler): def do_GET(self): if self.path == "/ssr": html = f"<h1>SSR time: {time.time()}</h1>" self.send_response(200) self.send_header("Content-Type", "text/html") self.end_headers() self.wfile.write(html.encode()) elif self.path == "/csr": html = """ <div id='root'>Loading...</div> <script> fetch('/api/time').then(r => r.json()).then(d => { document.getElementById('root').innerText = 'CSR time: ' + d.time; }); </script> """ self.send_response(200) self.send_header("Content-Type", "text/html") self.end_headers() self.wfile.write(html.encode()) elif self.path == "/api/time": body = json.dumps({"time": time.time()}).encode() self.send_response(200) self.send_header("Content-Type", "application/json") self.end_headers() self.wfile.write(body) else: self.send_response(404) self.end_headers() if __name__ == "__main__": HTTPServer(("127.0.0.1", 8000), Handler).serve_forever() 启动后访问： ...

TCP 与 HTTP 的区别：分层、语义与选型

副标题 / 摘要 TCP 是传输层协议，HTTP 是应用层协议。二者的职责与语义完全不同，但经常被混淆。本文用工程视角梳理差异与选型。目标读者需要排查网络问题的后端工程师想理解协议分层的开发者 Web 服务与客户端开发人员背景 / 动机很多线上问题都源于“层次混淆”：把 HTTP 的问题当 TCP 处理，或把 TCP 的问题当 HTTP 处理。理解分层，是定位问题与做技术选型的基础。核心概念 TCP：可靠、面向连接的字节流传输 HTTP：在传输层之上定义请求/响应语义分层模型：传输层解决“怎么送到”，应用层解决“送什么” 实践指南 / 步骤先看连接层：是否能建立 TCP 连接（握手、丢包、重传）再看应用层：请求是否符合 HTTP 协议（方法、头、状态码）分层排查：TCP 通了但 HTTP 失败，多半是应用层问题选型时分清职责：HTTP 可以跑在 TCP 或 QUIC 上常用诊断命令： # 看 TCP 连接建立 nc -vz host 80 # 看 HTTP 层返回 curl -v http://host/ 可运行示例先在本机启动一个 HTTP 服务： python3 -m http.server 8000 再用 socket 直接发 HTTP 请求： ...