从三十年前的一个优化项目上能够学到什么

前几天团队聚餐，喝了点酒话就多了，最后聊到93、94年给电信做计费系统的往事。当时电信都是后付费业务，客户先消费，月底统一计费，然后收费。那时候每个月缴费是从15号开始，到下个月15号之前缴费就不收滞纳金。

我93年第一次和泉州邮电局交流新一代计费系统的时候，就问他们，为什么要15号才开始收费呢？他们说收费时间肯定越早越好，他们也可以早点回收资金，同时降低欠费的成本。另外一方面，电总也有把C3本地网收费时间提早到5号的目标，只是因为技术原因，目前还无法实现这个目标。

长市话的计费信息在各个县的交换机上产生，并可以写入工业磁带。一般是在下半月开始，各县会开始给C3数据中心送来第一批磁带，本地网开始处理磁带。等下个月1号的时候，各县会把最后一批磁带送到。本地网计费中心要做的第一步是通过读取工业磁带里的话单信息生成话单文件，等文件全部读完，开始做一次批价，等所有话单全部完成批价后，会对一些大客户根据协议进行统一优惠处理，并对一些政策性单位进行减免处理。最后形成长市话话费数据。根据号段分别归结到各个C4网。然后写入磁盘，由各县取回。县里拿到的是FOXBASE文件格式的磁盘文件，已经按照县里的营业收费点做了处理。各个营业点拿到收费文件后才能开始收费。而交费者也只能到其号段所在的营业厅缴纳话费。

在这个过程中，每个环节都需要时间，因此一般来说要到下个月10号以后才能够完成收费的准备工作。我们分析了邮电局长市话计费的整个流程后，发现其中最耗时的是长话读带的过程。以前在使用国产的磁带机读取磁带的时候，完成一盘磁带的读取需要一个多小时。每个月处理100多盘磁带，哪怕加班加点，都需要10多天的时间。为此在93年这个新一代长市话计费系统的项目中，泉州电信采购了一台富士通的高速工业磁带机。用它替换了原来的磁带机后，我们测试了一下，速度确实比以前快了不少，不过仍然需要30多分钟。

当时我们对计算机的认知十分浅，对高速工业带机的工作机制也不甚了解。因此刚开始的时候对如何提高读带性能也是一头雾水。不过基于一台几百万的小型机肯定比一台几万块钱的PC机性能更好的认知，我建议把磁带机接到小型机上试试。我们先把磁带机接到VAX 4400上，读带速度一下子提高到20分钟左右了。确实是越高档的计算机上越快啊，于是我们又把磁带机接到了VAX6510上，这回没那么幸运了，速度略有提高，大概18分钟左右可以读完一盘磁带。在此期间，启用写话单文件的文件缓冲区以及磁带机的读缓冲区发挥了一定的作用，不过加大到一定程度后，哪怕我用再大的读写文件缓冲区，都无法进一步提高性能。

按照富士通的官方手册上所说，只需要20多秒就可以读完一盘磁带的，为什么我们的读带程序会这么慢呢？在读磁带的时候，我发现磁带的旋转是转一下停一下并不是连贯的。于是我写了个测试程序，只是把一盘磁带完整的读一遍，并不把读到的数据写入文件中。奇迹出现了，磁带不停顿的高速旋转起来，30秒钟左右就完成了一盘磁带的读取。

原来磁带机走走停停的原因是因为读带程序写文件的时候的IO打断了磁带机IO，程序读取磁带的速度与富士通工业带机的性能不匹配，从而导致了读带缓慢。找到原因后，优化起来就不难了。于是我设计了一个多线程架构的读带和处理框架，IO线程只负责读取磁带，然后把读到的数据块写入一个内存缓冲区中。另外创建几个处理线程，使用PV操作从缓冲区中读取数据块，并进行批价处理，然后写入数据库。因为当时的RDB数据库不是线程安全的，所以最终的架构要复杂一些。

批价线程完成批价后再放入一个话单入库队列，由数据库写入进程完成话单写入。经过这样改造后，一盘磁带在40秒钟左右就可以完成读带到入库的全过程了。以前一个多小时仅仅完成了一个读带的环节。经过改造后的系统，一天时间就可以十分轻松的处理完所有的长市话磁带了。

后来我们又逐一分析了比较耗时的环节，利用DDN线路把小型机的终端下发到了各个营业点，将原本下发给各地市的FOXBASE文件变成了RMS数据库的数据，给每个县创建了一个独立的RMS数据库。这样就把数据下发的时间又缩短了2-3天，最终实现了5号开始收费的目标。

这个今天看来十分简单的优化案例，在30年前还是轰动了全国电信行业的，连时任邮电部副部长，电信总局局长的周德强都亲自跑到泉州来考察这个系统，我也很荣幸的为周部长演示了读带过程。虽然30年过去了，这个技术已经不值一提了。不过这个中的一些思想依然对我们今天的系统优化有所帮助。

在优化过程中了解了硬件的能力极限，并找出影响应用达到硬件能力极限的原因是解决这个问题的关键。在找到这个关键之前，哪怕升级硬件（把读带从一台4M内存的PC机迁移到总线带宽，内存（64M）都要远远优于PC机的小型机上，虽然也获得了十分可观的性能提升，但是并没有真正的打破应用的瓶颈。真正解决问题的是发现了高速带机读带停顿的原因并通过避免文件IO来解决的。

了解硬件的能力极限是目前大多数DBA没有能力做到的，因此他们在做优化的时候，不知道是不是目前已经做到位了。十多年前，我遇到过一个用户，他们使用一台SUN SPARC 10000做数据库服务器，有些比较大的统计分析操作执行时间比较长，而从应用上已经很难优化了。他们听说新一代的SUN SPARC服务器的性能有了大幅提升，于是做了一次升级。新系统上线后发现不但没有获得预想到的性能提升，反而所有的业务都变慢了。我经过分析，新的SUN SPARC CPU的核数与线程数增加了，不过主频从3.0G+降低到了2.0G，单核性能反而比以前下降了。因此他们的一些扫描操作都不同程度的变慢了。进一步分析发现，他们的总并发量并不高，以前的SUN 10000的CPU使用率也很低，要解决他们的这个问题，在当时他们只要加大扫描操作的并行度就达到提高响应时间的目的了，换硬件是花了钱还没解决问题。

从这个三十年前的优化案例中可以学到的另外一件事是优化是要有目的性的。三十年前的IT相对比较简单，信息系统主要还是解决业务方面的问题，而不是以管理为目的。因此当时我们的目标只有一个，那就是把收费起始日期从15号提前到5号，如何在5号前完成所有的账务处理并向各个县级单位下帐。这时候我们的优化可以从一切角度去做，技术上只是很小的一方面，改变营业厅的收费模式，采用以小型机为核心的集中式数据库的多点收费系统等，都大幅减少了账务出账、分发等的时间，在这里我们起码节约了3天的时间，如果没有这些工作，这个任务也不可能完成。

而现在的信息化建设就复杂的多了，业务系统中的大量的上级部门的管理需求有时候成为了导致性能问题的主要因素。一套系统上线后，管理职能部门感觉管理抓手不够硬，一线业务人员也叫苦不迭，认为一些变态的管理让业务做起来十分不顺。出现这种情况很大程度上是因为甲方缺乏合格的产品经理，因此把这项工作交给了对业务一知半解的乙方开发团队。

系统优化从需求分析开始，需求优化以充分利用资源为主导思想，这两句话说起来似乎很简单，要做好其实也不易。想想三十年前，我们就已经能够从实际出发去解决问题了，面对更好的技术生态，更好的IT技术，更强大的计算机系统，只要秉承这些思想，还是应该能把优化工作做好的。