前阵子一个TW朋友跟我抱怨他们的文档发布很慢。正常发布需要一个晚上才能完成发布。中间如果出点错，就得重新发布，那么中间是漫长的等待。
不像MS Word或者InDesign这样所见即所得的软件，结构化文档源文件是XML格式的，就像计算机代码一样，不能直接使用。想要使用，必须先发布成PDF、HTML、ePub等格式。想起从业这些年，围绕着结构化文档的发布发生过很多故事，今天就来聊聊这个话题。
- 1 -
小A的故事
先来分享一个故事。有一个朋友，暂且叫小A，他们公司建设了结构化文档系统。发布的XML文件倒不大，一个文件生成的PDF有20-30页这样子，一个包里有200来个这样的文件，这样的包一天要发很多。关键的是这个发布程序不能出问题，因为后边的工作是等着这个文件才能展开的。如果发布不出来会直接影响企业的运行。
不巧的是这个发布程序有时候会无缘无故卡住，一旦卡住不管等多久都不会有结果。他们也找过实施方案的供应商，但是找不到卡住的原因，唯一的修复办法是重启服务器（万能的重启大法）。
小A是负责人，文档发布不出来下游的人就会找他，这可让他苦坏了。修复问题的办法倒也简单明了，但是就是每天过得提心吊胆的，随时准备着远程登录到服务器重启。休假的时候也要随身带着电脑，电话一响就紧张。
这样的日子过了好久。后来他告诉我他们找到一个解决办法，就是做一个定时重启服务器的程序，每天凌晨3点在不执行发布任务的时候重启服务器。
回想这个故事，首先是难过，感叹小A这些年过得不容易；其次是再次提醒我结构化文档发布程序稳定的重要性。
- 2 -
文档发布过程
作为TW，当文档发布很慢的时候，我们能做点什么事情呢？
毕竟术业有专攻，文档工程师的主业是文档创作，软件系统的事情可以找IT部门或者供应商。但是，了解一下内幕，我们会变得不那么被动。也可以从自己能把控的方面（比如：调整内容），为顺利发布提供帮助。
以将DITA文档发布为例，发布成HTML的过程是这样的：
发布成PDF的过程则有些不同，是这样的：
发布过程中发布HTML很少出问题，出问题最多的是发布PDF。主要的原因是因为发布HTML的时候是一个topic一个topic地处理的。发布PDF则需要将所有的topic合成为一个文件，然后处理。当发布文档很大，比如：上万页，这对服务器的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将文档中的图形精度降低，让图形文件变小
这两个措施都是减小发布程序的工作量，让它在可承受的范围内完成它的工作。TW可考虑：
-
我的文档能否分成2个或者多个文档或者部分呢？每个文档或者部分单独发布成一个PDF文件，这样一个文档由多个PDF组成。
-
我文档中的图精度是否没必要那么高呢？曾经碰到过过一个图达近100M，后来打开文件将图形尺寸缩小，将图大小放在5M以内可以大大提高发布效率？
2.4样式代码分析和调优
这里虽然叫样式(Stylesheet)，但是其实中间是有数据处理逻辑的，它由编程语言实现，如：XSLT。
合格的程序员都知道快速排序比冒泡排序效率高。但开发样式的小伙伴一般很少是计算机科班出生，不一定知道。
开发样式表的时候，不会考虑到内存和CPU的占用的问题。一不小心一个嵌套就能吃掉一大块内存却浑然不知，或者让CPU白忙活一阵却做的无用功。
这时，可以让懂程序开发的小伙伴帮样式开发人员分析样式处理逻辑中内存和CPU利用的问题。
2.5改装发布程序，用多台服务器支持发布，然后合成
这个难度最高，轻易不要考虑使用这种方式。 因为它需要系统架构师、高级工程师以及高级样式开发配合，而且开发和维护成本可能很高。 这里就不展开了。
- 4 -
最后的话
不知道小A最近过得怎么样，不知那个发布程序是否还那么恼人，得打个电话问问。
希望每个TW都能够顺利发布自己的文档，过上无牵挂的日子。
