通过分析内存来优化.NET程序

通过分析内存来优化.NET程序

最近在做一个MSMQ的Agent服务,在这里分享一下这个服务在优化的一点经验,通过分析内存更准确地定位出程序中存在的性能问题,从而让程序的性能以倍数的提升.

问题的引发

由于通过.NET MSMQ的Client实现消息分布和故障转移实在测试效果并不理想..所以决定实现一个MSMQ的Agent服务,由于有网络编写的经验所以对实现的效果还有很有信心的.可惜最终实现出来的效果实在惨不忍睹...4个连接并发消息写入只有150/秒,实在是完全坑爹的结果!在架构上的设计并不存在问题,所以问题一定存在程序实现过程中,以往的经验告诉自己做内存分析是最直接的办法.

问题排查一Buffer没正常回收到Pool

由于在测试过程CPU使用率并不高,所以怀疑是Buffer没有回收到Pool导致

从分析的结果来说,的确是自己在写代码的时候犯错了...存在大量的buffer被Pop出来导致大量内存被创建.但从代码流程上来看找不到任何原因.

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不会报错坑爹啊...

public  void  ToProtocolData(HttpData httpbase)
        {
            httpbase.Action = Action;
            httpbase.Message = this ;
            OnToProtocolData(httpbase);
            ;
        }

适当地修改一处程序问题解决.

吐能力提高但CPU占用资源过高

经过上面程序的修复4连接的秒吞吐能力由原来每秒150左右,上升到每秒2100/秒.得到的效果是非常的明显的,但总的来说CPU占用资源还有点过高,为了验证上一次修复的问题又进行了一次内存分析,分析的结果如下:

分析说明了一个问题由于Assembly.GetName()导致了大量的string创建,代码如下:

value = string .Format( "{0},{1}={2}" , type.FullName, type.Assembly.GetName().Name, JsonConvert.SerializeObject(Message));

适当地修改一下

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我们最好是从设计层面上控制对象的创建,这是最直接有效的办法.

可靠、高性能的Socket TCP通讯组件
开源数据库访问组件
c#组件设计交流群：47164588 
c# socket :136485198  微博http://weibo.com/ikende