由于各种原因我们总是要与公司各种老项目打交道。天有不测风云，谁也不知道这坨屎山会从哪个方向把你的嘴塞的满满的，还不让你吐出来。既然如此...那只能细嚼慢咽的吞下去吧。
说实在话，只要业务不死，那些老大伯项目就还有价值。更何况这个本就没什么人关注的项目突然被公司高层盯住了。说好几个客户都会用到这个系统，并且必须要做好压测工作，不能有任何闪失。
然后这项工作任务就毫无征兆的落在我手上了，改造优化时间不到一周。既然如此，那就只好硬着头皮上了。
项目整体整个项目很“老”，用的技术栈是 .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文件中看到如下代码：
// OldActivationBll.cs
private List<T1> global_fields1; //
private List<T2> global_fields2; //
private T3 field3;
...
private void InitData(string code) {
var dataset = dal.GetInitData(code);
global_fields1 = dataset[0];
global_fields2 = dataset[1];
T3 = dataset[2];
...
}
public void Activate(string code) {
// 略过判断
InitData(code);
// 引用类全局变量进行各种操作
field3.Property1 = ...;
...
}
有很多细节我都忽略了，大致就是现在一个类中定义一堆变量，然后在InitData方法中对这些变量一一赋值。这样在其它地方，我都可以任意调用这些变量了。
这种有什么问题呢？其实这种webform式的写法对程序运行结果没太大的影响。只是我个人不喜欢这种编程模式了，因为这样非常容易造就意大利面条式的混乱。让人看的非常头痛，维护起来很苦难。特别是换人之后，因为类全局变量哪里都能被修改，不熟的人很容易导致非预期的结果与错误。
当我正阅读代码并尝试优化这种结果时，发现事情并不是那么简单。
这是dal.GetInitData的代码
// OldActivationDal.cs
public DataSet GetInitData(string code)
{
string sql = @"declare @code nvarchar(250)
declare @bid int
declare @aid int
declare @usedId uniqueidentitfier
declare ...
select top 1 * from table1 where code=@code
select @bid = bid, @aid= aid from table1 inner join table2 on ...
select ...
-- 此处省略余下10几行select";
var dbset = dbhelper.ExecuteDataSet(sql, new parameter[] { ...});
return dbset;
}
看到这里是不是很惊讶，我当时是震惊的。我当时的反应是正常人应该不会这么写吧。这真是“一把嗦”的写法，把所有业务场景用到的前置对象一次性查出来赋值给对应的字段，然后有需要的就引用这些对象。这个方法的引用数是12......。
毫无疑问，这种写法问题很大，因为将多种业务场景的数据一次性查出来，也不管到底用不用得上，这是种对资源的绝对浪费。况且这对于数据库来说也是很大的浪费，因为将多个语句合并成了一个大事务执行。
这种优化手段就简单了，就是将一个大事务的sql语句，拆分成多个小事务的sql语句。不偷懒，多写几个方法按需给对象赋值。
这里面还有一个优化点是用到了缓存，在原来十几个sql查询中，还有3个查询语句是基础数据（如渠道以及资源等一些基础数据）。
具体代码错误前面提到的都还是设计上与流程的问题，还有一些明显的错误就是属于代码的写法错误了。在做了上面的改造措施之后，在我自己的本机做了同样的压测，结果令人尴尬。吞吐量只有100左右。这明显在我的意料之外的，这说明我优化效果不好。然后我继续详细找代码的问题，同时我写了个慢查询语句给db同事查看，让其导出测试同学压测的那个时间段的结果。期间还真让我发现了一些比较明显的问题，如下面的多任务写法：
List<Task> taskList = new List<Task>();
object lockObj = new object();
string[] requestIds = bookId.Split(",");
List<Resource> result = new List<Resource>();
foreach (var id in requestIds) {
taskList.Add(Task.Factory.StartNew(delegate() {
var resource = _resourceService.GetBookAsync(id).Result;
if (resource != null) {
lock (lockObj) {
result.Add(r);
}
}
}));
}
Task.WaitAll(taskList.ToArray());
return result;
大家来看下这段代码都有哪些问题呢？如何优化呢？这个后面我再给出我实际中的优化方法
数据库方面的优化找不到其它明显的代码问题就开始着手是不是数据库，sql语句的问题了。
与此同时，db也已经把结果导出给到我了，好家伙，排名第一（最耗时）的就是前面我说的那个十几个查询合并为大事务的那个方法sql语句。紧追其后的就是另一个查询语句，就是查询该用户是否已经使用过该资源。该语句join了多个表,并且关联的表都是百万级数据量的，并且条件很多（有5个），写法如下
select a.Id,a.Code,a.Status,b.Type,a.ChannelId,c.ActivateTypeId,a.Bid,a.UserId,b.Name,d.Did,d.Dtype
from a
inner join b on a.Id = b.Id
inner join c on b.uid = c.uid
left join d on d.Bid = b.Id
where a.UserId = @userId and a.Bid = @bid and a.ChannelId = @channelId and a.Status = 1 and d.DeviceCode = @deviceCode;
看到这个语句的第一想法是什么？
语句有问题？NO，而是检查数据库对应的字段是否有索引，如果没有命中索引，则会导致全表扫描，特别还join的是大表。结果也让我有点失望，索引每个字断都建了。我随即断点将那些条件的值拼成sql语句到线上环境执行，结果发现速度非常慢，足足有15-30秒波动。想了大概几分钟，立马得出了一个结论——索引的问题，给目标字段建立索引针对这种情况效果不大，而是要针对这种热调用场景有针对性的建索引——即联合索引。我给a这个大表建立idx_UserId_Bid_ChannelId_Status的联合索引，然后去掉了无用的字段，这样就减少了要join的表和潜在的回表。建好之后再次执行，只用了300ms左右。
此时压测的结果已经提升到了200左右（真就无脑建索引就完事了!-_-!）。
其实除此之外，还有几个查询也是很慢的。就不细举例了，解决方案除了联合索引，还有一种优化手段是包含列的索引。这种手段常见于select子表join是非常有效果的，其目的是为了减少回表的次数，争取一次查询就能将数据在多叉树的节点上直接返回。
总结自此，完成这些改造手术之后的压测结果在我本机机器上是达到了200多吞吐。算是完成了领导临时交给我的任务吧。在部署到线上时，测试同学压测出来的结果到达了500。不过让我有点意外的是，技术总监还是毅然决定给服务器升配加负载。（小声嘀咕：我还以为可以减配呢）
那么总结这次的性能优化点可以简单的概括三点：
- 架构层面（即分层要明确，减少重复的对象构造）
- 代码层面（减少明显的编程常识错误，如尽量避免多任务共享变量；还有不要偷懒...）
- 数据库层面（不要执行大的sql语句，要将大的拆成多个小事务sql语句，建对索引会省很多事）
关于具体实施，特别对手是老项目时，一定要本着“能不改原来的代码就不改为第一定律”。把这些老酒用新瓶包装起来。因为你永远也不知道你改动了其中一处地方，会给项目造成多大的伤害。
最后在结束本文之前，我给出之前代码的优化版本。在优化之前我们先清楚代码有问题。
很明显的有两个问题：
- 多任务并行调用异步方法，在遍历中共享了result对象，并通过上锁添加方法返回的结果
- 直接调用了异步方法
GetBookAsync.Result
这两点碰到一起了，这让本不富裕的服务器资源更是雪上加霜。
下面是我优化的版本
string[] requestIds = bookId.Split(",");
var taskList = new Task[requestIds.Length];
var result = new Resource[requestIds.Length];
for (int i = 0; i < requestIds.Length; i++) {
var idx = i;
taskList[idx] = Task.Run(() => {
}).ContinueWith(t => {
result[idx] = t.Result;
});
}
Task.WaitAll(taskList);
return result.ToList();
这是我想到的优化的版本，这样既能做到无锁编程，又可以不用阻塞异步方法。硬要说其它的问题的话，那就是requestIds的数量是潜在的问题点，因为数量非常多的时候，这个时候就会给系统带来很大的负担，最终也会引起API服务或数据库宕机的情况。这个时候其实我们可以通过PLINQ解决这点，通过分区来取得最佳性能。
好了这篇文章就到这里了。
本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。