Mikel
[转载]通过分析内存来优化.NET程序 – smark – 博客园.
最近在做一个MSMQ的Agent服务,在这里分享一下这个服务在优化的一点经验,通过分析内存更准确地定位出程序中存在的性能问题,从而让程序的性能以倍数的提升.
问题的引发
由于通过.NET MSMQ的Client实现消息分布和故障转移实在测试效果并不理想..所以决定实现一个MSMQ的Agent服务,由于有网络编写的经验所以对实现的效 果还有很有信心的.可惜最终实现出来的效果实在惨不忍睹…4个连接并发消息写入只有150/秒,实在是完全坑爹的结果!在架构上的设计并不存在问题, 所以问题一定存在程序实现过程中,以往的经验告诉自己做内存分析是最直接的办法.
问题排查一Buffer没正常回收到Pool
由于在测试过程CPU使用率并不高,所以怀疑是Buffer没有回收到Pool导致
从分析的结果来说,的确是自己在写代码的时候犯错了…存在大量的buffer被Pop出来导致大量内存被创建.但从代码流程上来看找不到任何原因.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
public override void MessageWrite(IMessage msg, BufferWriter writer) { HttpData hb = msg as HttpData; try { using (hb.Message) { msg.Save(writer); } } finally { if (hb != null) { hb.Message = null; HttpDataPackage.HttpDataPool.Push(hb); } } } |
分析结果已经说明了问题所在,所以调试了一下程序,发现问题的根源是HttpData的Message为空,但using不会报错坑爹啊…
|
1
2
3
4
5
6
7
|
public void ToProtocolData(HttpData httpbase) { httpbase.Action = Action; httpbase.Message = this; OnToProtocolData(httpbase); ; } |
适当地修改一处程序问题解决.
吐能力提高但CPU占用资源过高
经过上面程序的修复4连接的秒吞吐能力由原来每秒150左右,上升到每秒2100/秒.得到的效果是非常的明显的,但总的来说CPU占用资源还有点过高,为了验证上一次修复的问题又进行了一次内存分析,分析的结果如下:
分析说明了一个问题由于Assembly.GetName()导致了大量的string创建,代码如下:
|
1
|
value = string.Format("{0},{1}={2}", type.FullName, type.Assembly.GetName().Name, JsonConvert.SerializeObject(Message)); |
适当地修改一下
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
value = string.Format("{0}={1}", GetTypeName(type), JsonConvert.SerializeObject(Message));private static System.Collections.Hashtable mNames = new System.Collections.Hashtable(1024);private static string GetTypeName(Type type){ string name = (string)mNames[type]; if (name == null) { lock (mNames) { name = (string)mNames[type]; if (name == null) { name = string.Format("{0},{1}", type.FullName, type.Assembly.GetName().Name); mNames[type] = name; } } } return name;} |
经过以上的进一步优化后,服务的效果算是比较理想,完全满足了现阶段的需要.
意外的发现
从测试分析的结果看来,Newtonsoft.Json这个组件还有针对性优化的空间
针对以上分析,Newtonsoft.Json存在的问题应该如何优化,那就要留大家思考了.
总结
其实很多朋友喜欢通过CPU计时来看程序的快慢,但得到的结果只能说明问题,但对于如何解 决这些问题,测试运行时间的结果似乎起不到什么作用.其实.NET程序有一个东西往往没有得到关注,MS在一些文档中要强调我们没有必要关心,这个东西其 实就是GC!的确我们对GC的工作直接可控性是没有,但有一点可以肯定的就是GC的工作由对象的创建导致,如果想控制GC我们最好是从设计层面上控制对象 的创建,这是最直接有效的办法.
