▲点击上方“大龙谈技术刊物”关注公众号

前段时间，一位台湾朋友向我抱怨他们的文档发布速度很慢。 正常的发布需要一个晚上才能完成。 如果中间出了问题，就得重新发布，等待的时间会很漫长。

与MS Word或此类所见即所得软件不同，结构化文档源文件是XML格式的，就像计算机代码一样，不能直接使用。 如果要使用它，必须先将其发布为PDF、HTML、ePub等格式。 想到这些年来在行业工作中发生的很多围绕结构化文档发布的故事，今天我们就来聊聊这个话题。

- 1 -

小A的故事

我先分享一个故事。 我有一个朋友，就叫他小A吧。他们公司建了一个结构化文档系统。 发布的XML文件并不大。 一个文件生成的 PDF 有 20-30 页。 一个包中大约有200个这样的文件。 一天内需要寄出很多这样的包裹。 关键是这个发布程序不能有问题，因为后续的工作就是等待这个文件启动。 如果不能释放，将直接影响企业的运营。

不幸的是，这个发布过程有时会无缘无故地陷入困境。 一旦卡住了，无论等多久都没有结果。 他们也联系了实施方案的供应商，但找不到卡壳的原因。 唯一的解决方法是重新启动服务器（通用重新启动方法）。

小A是负责人。 如果文件不能发布，下游的人就会来找他，这让他很痛苦。 解决问题的方法简单明了，但我每天都提心吊胆，随时准备远程登录服务器重启。 度假时我必须随身携带电脑，电话一响我就会紧张。

这样的日子已经过去很久了。 后来他告诉我，他们找到了解决办法，就是制作一个定时重启服务器的程序，每天凌晨3点不执行发布任务的时候重启服务器。

回顾这个故事，我首先感到心酸，感叹小A这些年过得并不安逸； 其次，它再次提醒我一个稳定的结构化文档发布程序的重要性。

- 2-

文档发布流程

作为TW，当文件发布缓慢时，我们该怎么办？

毕竟技术领域是有专业的，而文档工程师的主要工作就是文档创建。 对于软件系统问题，您可以联系IT部门或供应商。 但只要了解一点内部知识，我们就可以变得不那么被动。 您还可以从您可以控制的方面（例如调整内容）为顺利发布提供帮助。

以发布DITA文档为例，发布为HTML的流程如下：

发布为 PDF 的过程略有不同，如下所示：

在发布过程中，发布HTML时很少出现问题，但最常见的问题是发布PDF时。 主要原因是因为发布HTML时，是一一处理的。 要发布 PDF小程序开发文档联系电话，您需要将所有内容合并到一个文件中，然后对其进行处理。 当发布的文档很大，比如几万页时，这对服务器的CPU、内存和磁盘都是一个考验。

就像小孩子吃饭一样。 小口吃是可以的； 如果你的嘴里一下子塞满了食物，你吃东西就会很慢，甚至可能会窒息。

- 3-

性能分析和调优

如果遇到这种情况该怎么办？ 总的来说，分析和性能调优思路如下：

上图中，1.1、1.2、2.1、2.2、2.3都可以由TW操作或协调； 2.4 和 2.5 更加困难，需要系统构建者的帮助。

下面是一些细节，看看TW就知道了。

如何查看服务器硬件资源是否被利用？

无论是物理服务器还是云服务器，都具有监控功能。 例如下面是阿里云服务器的监控信息：

从这里我们可以看到服务器近段时间的资源利用率图。 特别关注这三个指标：1）CPU使用率，2）内存使用率，3）磁盘读写。

如果这三种资源的利用率很低（低于30%），则说明服务器硬件资源没有得到利用。

1.1 调整设置和 1.2 升级发布引擎

1）调整发布器的内存设置

很多发布程序都是使用一种叫Java的语言开发的，默认最大内存是1G。 这时候即使你的服务器有16G，也只会使用1G。 然后，你可以将内存设置为10G（需要为操作系统和其他程序留一些）。 如果是32G的服务器，可以设置为26G。

2）配置可同时运行的发布任务数量

一个发布程序一般可以同时执行多个发布任务。 CPU利用率低意味着计算能力没有被使用，即CPU正在等待工作。 适当增加可同时执行的发布任务数量，保持CPU繁忙。

需要注意的是，发布引擎一般是按照CPU核心来销售的（这也是很多服务器软件的商业模式）。 免费程序只能使用 1 个 CPU 核心。 价格越高，支持的核心越多。 核心越多，程序可以同时使用的CPU就越多，可以执行的任务就越多。

如果发布任务数量增多，CPU利用率仍然较低，可以查看自己购买的发布引擎，考虑是否需要升级。

2.1 升级服务器硬件

硬件资源的成本每年都在降低，所以如果升级服务器硬件可以解决问题，就不要碰软件，这是成本最低的。

2.2 拆分文档，使发布的文件更小，更易于发布 2.3 降低文档中图形的精度，使图形文件更小

这两项措施都减轻了出版商的工作量，使其能够在可承受的范围内完成工作。 台湾可以考​​虑：

2.4 风格代码分析与调优

这里虽然叫()，但中间其实有数据处理逻辑，是用编程语言实现的，比如XSLT。

合格的程序员知道快速排序比冒泡排序更有效。 不过开发风格的朋友一般很少是计算机专业出身的，也不一定认识。

开发样式表时，不考虑内存和CPU 使用情况。 不经意间，嵌套可能会在不知不觉中占用大量内存，或者可能使 CPU 忙碌一段时间，但做无用的工作。

这时候可以请懂程序开发的朋友帮助样式开发人员分析样式处理逻辑中的内存和CPU利用率问题。

2.5 修改发布程序，使用多台服务器支持发布，然后综合

这是最困难的，所以不要轻易考虑使用这种方法。 因为它需要系统架构师、高级工程师、高级风格开发人员的配合，开发和维护成本可能会很高。 这里就不展开展开了。

- 4-

最后的话

不知道小A最近过得怎么样。 我不知道发布程序是否仍然那么烦人。 我需要打个电话去了解一下。

希望每一位TW都能顺利发布自己的文档，生活无忧。