本帖最后由 viphk 于 2010-12-28 21:45:55 编辑

解决方案 »

  1.   

    WAS等压力测试,资源是否及时释放,编码问题
      

  2.   

    滥用Session集合保存数据,比较容易产生这类“人数多一点就崩溃”的问题。
      

  3.   

    另外,假设你对一些持久数据还不善于进行数据缓存处理,而是读取数据库,那么对于不需要保证数据绝对一致性的查询,应该使用(以SQL Server为例)“with(nolock)”方式来查询。
      

  4.   

    嗯 不需要频繁更新就缓存
    最主要的应该是SQL优化的问题把
      

  5.   

    缓存啊 懒加载啊 当然sql优化是个大问题哦
      

  6.   


    SQL优化
      

  7.   

    见议在缓存和sql优化方面做功夫
      

  8.   

    估计是锁表了,一些SQL语句都会进行锁表,他在执行的时候,会锁定涉及到的表,这是其他的就不能操作这个表的,必须等待解锁。如果某个锁表的操作比较耗时,那么就会造成等待,这个时候就会很慢,如果照成连环的形式,一个锁一个,那就更悲剧了。可以用企业管理器,开查看一下是否有锁表的情况。在 管理->当前活动 ,里面可以看到是否有锁表(堵塞)的情况。
      

  9.   

    如果select操作很多,那可以可以考虑缓存,还有你的数据库尽量用存储过程来操作(因为存储过程可以缓存),多次执行速度有保障,还有就是加索引,尽量的减少数据库的操作次数,能一次取出的数据就一次取出,不要分多次取出。对于分页,一次就取出要的数据,不要一次性取出全部。少用datareader,多用dataset。数据库中不要用到游标什么的,速度慢,可以用其他的方式来替代。
    对于有lock的地方,看看要及时的释放。
    还有就是viewstate这个,有些不需要的,就禁用,GridView才生的ViewState在页面上也是相当的恐怖。
    能在客户端解决的事情,就不要到服务器端再解决。还有就是 合理的使用AJAX。
    或则直接的方法就是给你的硬件升级升级。