LucidChart 提供在线编辑流程图、网络拓扑图、ER 图、 UML 图以及脑图等多种图表服务，有超过 7 百万的用户，因其简单直观的交互体验和强大的多人协作功能，是可以替代 Visio 的最佳选择。
在 Lucid，我们使用面向服务的架构来建设我们的系统。其中字体服务(font service)就是其中之一，它负责根据字体族名称和 unicode 编码范围来提供相应的字体服务，同时也对用户上传的字体进行校验和检查。在生产环境中，该服务的负载一直很高，这一点超出我们的预期(使用或等待 CPU 的平均线程数)。特别从去年开始，我们注意到字体服务的负载高的惊人，特别是在晚上这样的流量低峰时期。
幸运的是最终我们找到了根本原因，并通过改进大大提高了服务的整体性能和稳定性。通过下面的内容，您将了解到我们是如何做到的。
图1: 字体服务在变更前后服务器平均负载对比
通过火焰图来调试和发现问题
我们从 Netflix 找到了一个非常棒的火焰图工具，并部署到生产环境。 此工具可以将多个不同调试分析工具的数据组合在一起并生成火焰图，以可视化的方式展示服务器和 JVM 的资源使用情况。
如下图所示，每个矩形表示一个栈帧，同时矩形的宽度代表了资源(比如 CPU 时间)的使用情况，Y 轴表示调用栈。通过识别那些宽的矩形块，就能快速缩小问题范围。在调试和排查字体服务时，它极大地帮助了我们。
图2: 高负载时字体服务中一台服务器的火焰图
在高负载状态下，我们对字体服务收集数据并生成了几个火焰图。下图是其中之一，并且特别展示了 JVM 相关栈的部分。可以分析得出，大部分时间都花在了 libz.so 这一步(gzip 使用该库进行压缩/解压缩操作)，剩下大部分时间都花在了 XML 转义和 UTF-8 编码上。
图3: JVM 相关栈活动的局部火焰图
找到慢的原因
首先多啰嗦几句这个字体服务的一些背景情况。我们将所有字体相关数据存储在 Amazon S3 中，具体来说是将每个字体的每个 unicode 范围分别存为一个 S3 object。当其他服务请求为了获取字体族，一组 unicode 范围，或者是用户自定义字体时会向字体服务请求字体数据，接着字体服务将字体数据包裹在 XML 中返回。
功能非常简单，并没有什么明显的密集型计算。但是对于出现的高负载问题，火焰图帮助我们识别出了问题所在—— libz，XML 转义和 UTF-8编码都使用了大量的 CPU。
但是为什么会产生这么多编码和压缩的消耗?记得前面提到晚上时间的负载反而是最高的吗?我们的晚上(美国山区时间)正好是亚洲地区的白天，该地区很多用户都使用中文、日文或韩文等亚洲语言。会进行大量的 gzip 解压缩 → UTF-8解码 → XML 转义 → UTF-8编码 → gzip 压缩。相比于拉丁语系，单个 CJK 的 unicode 范围比拉丁语系的 unicode 范围大2个数量级(1MB：60KB)。所以上述的转换过程都压到了 CPU 上，特别压缩和解压缩，以及 XML 转义这类操作。
如何改进?
字体服务对请求的响应本质上只是 S3 上原始数据的集合。它确实需要执行一些重要的附加任务，如权限检查和从字体族中检索名称。但是，字体服务根本没必要挡在 S3 前面来代理那些字体数据!所以解决办法很简单， 直接用包含 S3 object 的链接(就是那些字体数据)的列表作为响应返回，字体服务不再从 S3 下载并重新编码字体数据。所以从图1中可以看出负载几乎降低到可忽略的程度。
总结
通过调试分析生产环境，我们能够找到并消除那些不必要的任务和工作，进而降低服务器负载。
使用例如火焰图之类的分析工具(profiling tool)来帮助识别 CPU 高占用的操作。
压缩/解压缩和各种编码/解码的操作都是昂贵的。
如果客户端可以直接访问数据，那么相比代理(客户端去请求)数据，直接返回链接是最好的选择，可以显著提高整体性能。
本文作者：佚名
来源：51CTO