> For the complete documentation index, see [llms.txt](https://freebsd-journal-cn.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://freebsd-journal-cn.bsdcn.org/20200708-ji-zhun-ce-shi-tiao-you/we-get-letters.md).

# 读者来信

> 亲爱的回信实体，
>
> 在操作系统里，给聚变反应堆超频是怎么回事？

我不知道你们中有多少人写信来抱怨性能问题，因为只要我意识到信的内容，就把它们扔进了垃圾桶。有时这要花上几分钟，因为能写出哪怕勉强符合英语标准的信的人少之又少，而英语标准本身已经低得令人沮丧。FreeBSD 期刊是个有格调的机构。我们不曾、将来也不会接受短信投稿，因为大多数运营商已经把最适合回复的表情符号归类为不堪入目的淫秽内容而禁用了。

不过，我觉得有义务把你们的一些疑问扔进搅拌机里搅一搅。我看到一些读者想知道如何优化性能。

我有建议。很多建议。

归根结底就是：别。

拿你的服务器跟别人比、想碾压邻居的那种自然冲动，确实就是自然的。就像翻开石头找好吃的蛴螬。睡在树上眼馋上层阶级洞穴里那些自命不凡的灰熊。在《维生素 C 到底是什么玩意》出现的 20 年内死去。我们发明文明就是为了逃离痢疾、用泥巴清洁自己——还有基准测试。

这事如此自然，甚至出现在极客文化最神圣的圣物《星际迷航》里。在《深空九号》中，O’Brien 不断折腾卡达西空间站，想把它的性能调到他觉得能接受的水平。不是站长的标准。不是空间站居民的诉求。是他觉得能接受的水平。事实是，空间站工作得好好的。空间站抗拒他的折腾，因为它的软件知道系统应该如何运作，而他执迷的修修补补威胁到了系统的完整性。某个把我的 Trek 基因和“强迫性、无关紧要、细节测量”基因结合起来的人，肯定数过 O’Brien 多少次因为坚持给外星聚变反应堆超频而险些害死几百人。（“联邦 **hold my beer** 协会” 同时解释了所有《星际迷航》剧情漏洞和所有《星际迷航》剧情。自己查去。）

也许你的工作就是伺候服务器，你想知道自己干得怎么样。但机器对你的工作表现没有投票权。和你组织架构里的父进程做 IPC 吧。告诉你做得怎么样，那是你经理的职责。

但有些人偏要执意从系统里榨出几个百分点的性能。所有人都可能因此被吸进真空，这种风险你愿意让他们承担。

唯一重要的性能，是用户体验到的。

所以，把你那懒散的身子挪一挪，去跟用户沟通。

最好口头说。在最好的情况下，写作也是糟糕的沟通机制。能行的话，当面沟通。当然，除非有瘟疫。双向交流。和你的用户对话。

这意味着倾听。你不能趁别人对你喋喋不休无知的话时琢磨自己接下来要说什么。你需要处理他们的喋喋不休，从中提炼出含义。最好是他们想表达的含义。把你提炼出的含义呈现给用户，请求确认。我保证，用户的痛苦与数据库每秒发出多少次磁盘写入毫无关系。万一真有关系，我保证多个一两个百分点的性能也缓解不了他们的烦恼。

你不会享受这个过程。系统管理员守则第二条很明确：“人是个错误。”

但系统存在的意义就是服务用户。

他们披露的许多事情看上去与你无关。如果他们试图在上一千年的原型 Atom 处理器上跑你那华丽的客户端 JavaScript 应用，那肯定会慢。问题是不是出在他们的桌面十年前就该被送去“永恒毒性大垃圾堆”？是不是你的应用不适合这个组织？还是桌面和应用都是某个计算机盲批准的，那人担任采购职位的主要资格是能安抚董事会主席最让人头疼的孩子，让他别再用全新出炉的“今日烦心事”不停打给妈咪？

基准测试能帮你解决这个问题吗？不能。找到真正的问题。解决它。

不过，如果基准测试的自然冲动太过强烈难以抑制，把它升华到有用的方向去吧。

当然，设置监控，确保你的应用在合理的时间限制内响应。那更多是运维问题。把监控结果绘成图表，这样你就能看到性能随时间的变化。当有人说“升级后应用好像变慢了”，那张图要么让你宣布你早已知晓这个问题，要么让你有理由嗤之以鼻。

除此之外，挑一个用户为目标。你知道是哪个。那个问题用户。

给他们做基准测试。

启动你最喜欢的抓包工具。观察服务器和问题用户的机器之间的交互。抓包。分析。看看真实世界里发生了什么。做笔记。

dtrace、ktrace、truss。它们都是你的朋友。看着服务器干活。你的应用把时间花在哪里？做更多笔记和采样。

也许你能找到真正影响问题用户的症结。找不到的话，你也会学到关于你的环境和应用的大量（不太健康的）知识。

最终，你会被叫去和你组织架构里的父进程开会。也许是年度评估。也许问题用户终于闹得够凶，管理层不得不动一动，发出点表示关心的声音。他们问你最近在做什么时，你有一堆数据可以摆出来。也许那不是有用的数据，但没关系。你深入探究了环境的内部。你能证明自己花时间调查了问题用户的问题。包跟踪和 dtrace 结果，加上你大量的注释、箭头和连接不同段落的弧线，总能让人印象深刻。

是的，基准测试是人类的自然行为。而没有什么比生意更自然的了。

你，作为个人，时刻都在被基准测试。把你的基准测试做扎实。

这几乎和给聚变反应堆超频一样好玩。

有问题想问 Michael？ 请发送至 <letters@freebsdjournal.org>

***

**MICHAEL W LUCAS**（<https://mwl.io>）的最新著作是《Sudo Mastery, 2nd Edition》和《Terrapin Sky Tango》。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://freebsd-journal-cn.bsdcn.org/20200708-ji-zhun-ce-shi-tiao-you/we-get-letters.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.