1.确定是不是机器问题,换台服务器试试 看有没有类似问题。以前某个项目我遇到过一次莫名其妙的延时90秒 而且延时区域是无法编写的区域。
2.监控 请求日志 判断 延时区域 是那一段代码
服务器端:分别在beginrequest (开始请求),OnActionExecuting(方法执行前),OnActionExecuted(方法执行后),endrequest(结束请求),如果可以 再查一下iis 的请求接收记录
客户端:通过f12 network监控,查看请求开始时间 等待时间
对比 服务器端 和 客户端日志 找出 延时的区域属于那一块
嗯!思路很好,我一一测试后再另请教
只能笼统的说是竞争导致的。
代码中的估计要自己巴拉,这块出问题的情况千奇百怪(线程池啊,各种奇葩的单例实现,lock粒度有问题等)。
数据库上的比如连接池就设了1个,db操作中的锁。
是的,我的几乎每个BLL业务类都是单例模式,因为不想每次调用都new一个实例,因为也没有什么公用属性,都是形如下:
private static object locker = new object(); private static C_MemberBLL _instance; public static C_MemberBLL Instance { get { if (_instance == null) { lock (locker) { if (_instance == null) { _instance = new C_MemberBLL(); } } } return _instance; } }
多个请求时候确实有几个请求都用这个单例的实例,请问这样大量的都是这样的会有什么问题呢?赐教
@寂寞的博客: 这个单例没问题,除非实例化那个对象的成本很高(从你的描述中应该不是这样)。
我一般采用对比法
换个或换多个机器,如果情况依旧,可以排除网络问题。
然后进行跟踪调试,每次调用一个,看看是不是每个都那么耗时,如果是一个一个的不耗时,而2个或者更多的时候耗时增加.....就查时不时有数据库连接池的问题等等。
类似这样的问题和内存溢出的感觉一样,要仔细慢慢排除。从前到后,直至数据库