老项目的倔强——性能优化篇

老项目的倔强——性能优化篇

由于各种原因我们总是要与公司各种老项目打交道。天有不测风云，谁也不知道这坨屎山会从哪个方向把你的嘴塞的满满的，还不让你吐出来。既然如此...那只能细嚼慢咽的吞下去吧。

说实在话，只要业务不死，那些老大伯项目就还有价值。更何况这个本就没什么人关注的项目突然被公司高层盯住了。说好几个客户都会用到这个系统，并且必须要做好压测工作，不能有任何闪失。

然后这项工作任务就毫无征兆的落在我手上了，改造优化时间不到一周。既然如此，那就只好硬着头皮上了。

项目整体

整个项目很“老”，用的技术栈是 .net4.5 + 多层架构 + sqlsugar + mssql。为什么”老“要加引号呢？因为我很难想象这个项目只是3年前的项目（:摊手）。其中orm——sqlsugar我已经找不到开源的项目地址了（用的仅仅是静态dll），里面有很多写法我都找不到文档了。没关系，又不能不能用，我只要参照之前的写法不动就行了。

那么再来说现在这个项目要进行”手术“的地方：

首当其冲的就是目前这个项目经过测试人员压测，200并发，持续半小时以及100并发，增量并发到200持续1小时的压测结果是......

不到20吞吐量，CPU一直100%。根据目前产品给出的用户量，至少要达到120吞吐量。得到这个消息的我，当时人都麻了......真不夸张。我一度认为我要“死”在这个项目中了。

剖析项目

一边看代码一边骂人的过程就不说了，相信大家都是这么过来的。接下来要做的就是熟悉代码以及代码下的业务场景。涉及优化的业务场景看起来很简单，就是给定一个码，系统接收校验真伪，然后进行激活使用。

在经过非常艰辛的和跟我一样不熟悉这个业务的产品经理沟通下，确定业务方的需求和目的之后，剩下就是真正实施了。

代码层优化

首先我从最简单的开始着手，就是code review。找出能一眼看出问题的点，结果仅仅只是几处f12，就让我找到了”几坨屎“，虽然不愿意，但我还是只能捂着鼻子强迫自己掰开看看究竟。

层与层之间调用关系混乱

因为是多层，所以有BLL，DAL，Model三层。DAL引用ORM组建以及缓存组建，BLL引用DAL。DAL引用DBInstance。在实际查看中，我发现虽然BLL引用DAL，但是除了引用DAL之外，又初始化了DBInstance。缓存组建也是如此。在实际调用中，多次重复打开数据库连接以及缓存连接，这无疑是一笔不小的开销，而且还没有任何意义。

看到这个我要做就是优化层之间的调用结构。本着对老项目最小更改原则，我重新建了ActivationBll和ActivationDal文件，去掉多余的对象以及无用的IO连接。

代码逻辑的一把嗦

往下就是具体代码问题了，首先我就在原来的OldActivationBLL文件中看到如下代码：

有很多细节我都忽略了，大致就是现在一个类中定义一堆变量，然后在InitData方法中对这些变量一一赋值。这样在其它地方，我都可以任意调用这些变量了。

这种有什么问题呢？其实这种webform式的写法对程序运行结果没太大的影响。只是我个人不喜欢这种编程模式了，因为这样非常容易造就意大利面条式的混乱。让人看的非常头痛，维护起来很苦难。特别是换人之后，因为类全局变量哪里都能被修改，不熟的人很容易导致非预期的结果与错误。

当我正阅读代码并尝试优化这种结果时，发现事情并不是那么简单。

这是dal.GetInitData的代码

看到这里是不是很惊讶，我当时是震惊的。我当时的反应是正常人应该不会这么写吧。这真是“一把嗦”的写法，把所有业务场景用到的前置对象一次性查出来赋值给对应的字段，然后有需要的就引用这些对象。这个方法的引用数是12......。

毫无疑问，这种写法问题很大，因为将多种业务场景的数据一次性查出来，也不管到底用不用得上，这是种对资源的绝对浪费。况且这对于数据库来说也是很大的浪费，因为将多个语句合并成了一个大事务执行。

这种优化手段就简单了，就是将一个大事务的sql语句，拆分成多个小事务的sql语句。不偷懒，多写几个方法按需给对象赋值。

这里面还有一个优化点是用到了缓存，在原来十几个sql查询中，还有3个查询语句是基础数据（如渠道以及资源等一些基础数据）。

具体代码错误

前面提到的都还是设计上与流程的问题，还有一些明显的错误就是属于代码的写法错误了。在做了上面的改造措施之后，在我自己的本机做了同样的压测，结果令人尴尬。吞吐量只有100左右。这明显在我的意料之外的，这说明我优化效果不好。然后我继续详细找代码的问题，同时我写了个慢查询语句给db同事查看，让其导出测试同学压测的那个时间段的结果。期间还真让我发现了一些比较明显的问题，如下面的多任务写法：

大家来看下这段代码都有哪些问题呢？如何优化呢？这个后面我再给出我实际中的优化方法

数据库方面的优化

找不到其它明显的代码问题就开始着手是不是数据库，sql语句的问题了。

与此同时，db也已经把结果导出给到我了，好家伙，排名第一（最耗时）的就是前面我说的那个十几个查询合并为大事务的那个方法sql语句。紧追其后的就是另一个查询语句，就是查询该用户是否已经使用过该资源。该语句join了多个表,并且关联的表都是百万级数据量的，并且条件很多（有5个），写法如下

看到这个语句的第一想法是什么？

语句有问题？NO，而是检查数据库对应的字段是否有索引，如果没有命中索引，则会导致全表扫描，特别还join的是大表。结果也让我有点失望，索引每个字断都建了。我随即断点将那些条件的值拼成sql语句到线上环境执行，结果发现速度非常慢，足足有15-30秒波动。想了大概几分钟，立马得出了一个结论——索引的问题，给目标字段建立索引针对这种情况效果不大，而是要针对这种热调用场景有针对性的建索引——即联合索引。我给a这个大表建立idx_UserId_Bid_ChannelId_Status的联合索引，然后去掉了无用的字段，这样就减少了要join的表和潜在的回表。建好之后再次执行，只用了300ms左右。

此时压测的结果已经提升到了200左右（真就无脑建索引就完事了!-_-!）。

其实除此之外，还有几个查询也是很慢的。就不细举例了，解决方案除了联合索引，还有一种优化手段是包含列的索引。这种手段常见于select子表join是非常有效果的，其目的是为了减少回表的次数，争取一次查询就能将数据在多叉树的节点上直接返回。

总结

自此，完成这些改造手术之后的压测结果在我本机机器上是达到了200多吞吐。算是完成了领导临时交给我的任务吧。在部署到线上时，测试同学压测出来的结果到达了500。不过让我有点意外的是，技术总监还是毅然决定给服务器升配加负载。（小声嘀咕：我还以为可以减配呢）

那么总结这次的性能优化点可以简单的概括三点：

• 架构层面（即分层要明确，减少重复的对象构造）
• 代码层面（减少明显的编程常识错误，如尽量避免多任务共享变量；还有不要偷懒...）
• 数据库层面（不要执行大的sql语句，要将大的拆成多个小事务sql语句，建对索引会省很多事）

关于具体实施，特别对手是老项目时，一定要本着“能不改原来的代码就不改为第一定律”。把这些老酒用新瓶包装起来。因为你永远也不知道你改动了其中一处地方，会给项目造成多大的伤害。

最后

在结束本文之前，我给出之前代码的优化版本。在优化之前我们先清楚代码有问题。

很明显的有两个问题：

1. 多任务并行调用异步方法，在遍历中共享了result对象，并通过上锁添加方法返回的结果
2. 直接调用了异步方法GetBookAsync.Result

这两点碰到一起了，这让本不富裕的服务器资源更是雪上加霜。

下面是我优化的版本

这是我想到的优化的版本，这样既能做到无锁编程，又可以不用阻塞异步方法。硬要说其它的问题的话，那就是requestIds的数量是潜在的问题点，因为数量非常多的时候，这个时候就会给系统带来很大的负担，最终也会引起API服务或数据库宕机的情况。这个时候其实我们可以通过PLINQ解决这点，通过分区来取得最佳性能。

好了这篇文章就到这里了。