原文:【原创】构建高性能ASP.NET站点之三 细节决定成败

构建高性能ASP.NET站点之三 细节决定成败

  前言:曾经就因为一个小小的疏忽,从而导致了服务器崩溃了,后来才发现:原来就是因为一个循环而导致的,所以,对“注意细节“这一说法是深有感触。

  系列文章链接:

  构建高性能ASP.NET站点 开篇

  构建高性能ASP.NET站点之一 剖析页面的处理过程(前端)

  构建高性能ASP.NET站点之二 优化HTTP请求(前端)

  构建高性能ASP.NET站点之三 细节决定成败

  构建高性能ASP.NET站点 第五章—性能调优综述(前篇)

  大型高性能ASP.NET系统架构设计

  构建高性能ASP.NET站点 第五章—性能调优综述(中篇)

  构建高性能ASP.NET站点 第五章—性能调优综述(后篇)

  构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优(上篇)—识别性能瓶颈

  构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优(下前篇)—简单的优化措施

  构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优(下后篇)—减少不必要的请求

  构建高性能ASP.NET站点 第七章 如何解决内存的问题(前中篇)—托管资源优化—监测CLR性能

  构建高性能ASP.NET站点 第七章 如何解决内存的问题(前篇)—托管资源优化—垃圾回收机制深度剖析

  构建高性能ASP.NET站点 第七章 如何解决内存的问题(前中篇)—托管资源优化—监测CLR性能

本篇的议题如下:

问题的描述

细节的重要性

  问题的描述

  首先,描述一下故事的背景:(希望大家耐心的故事读完)

  在网站中,网页中的分页控件每次显示10条数据,每次点击下一页,就再次去取下一个10条数据。至于分页的方法怎样做,方法有很多,相信这点大家都知道。

  过程是这样的:在用户请求数据的时候(考虑到了用户的操作和网站的访问量)我会第一次取出500条数据,然后把数据放在缓存中,也就是说,我取出了50页的数据,放在缓存中,这样如果,以后用户请求第一页到第49页的时候,就直接从缓存中拿数据。

  如下图:

  

 

  第一个数据块:

  采用键值对的形式:字典保存

  如果用户请求到了49页以后,那么就再次从数据库中取出下一个数据块(包含501到1000数据),然后,现在内存中就有了1000条数据。

  至于缓存多久,数据什么失效,失效后怎么做,这里暂不谈论。(网站在这种缓存策略下运行的很好)。

  代码如下:

List<Product> products=GetDataFromCacheOrDatabase(condition,pageIndex,count….);

  代码的意思很清楚,从缓存中拿数据,如果缓存中没有对应的数据,那么就先从数据库中拿500条数据,然后放在缓存中,最后返回10条数据。

  后来,因为某些功能的需要,需要返回当前页的前6页数据和后6页的数据,例如:如果当前页是第12页,那么就要返回12页之前6页Product(也就是第6,7,8,9,10,11页的数据),和第12页后的页的Product(第13,14,15,16,17,18页的数据)。

  如下:

  

 

  当然,如果当前页是第5页,那么就把之前所有5页的数据都返回,另外再加上第5页之后的6页数据。

  这里就可能涉及到跨块获取数据,如:

  如果当前页是第48页的时候,那么返回前6页数据是没有什么问题的,那么后6页的数据就不足了,因为49,40也得数据可以从缓存的数据块中取到,至于51,52,53,54页的数据,就需要再次从数据库中读取,然后再次缓存(如果事先没有被缓存)。

  最后在缓存中的数据如下:

  

  然后调用方法:(伪码)

List<Product> products=GetDataFromCacheOrDatabase(condition,42, 126….); 

  上面传入的是从第42页开始的数据,也就是第48页的前6页和后6页的数据。

  这个方法的内部实现是这样的:

    1.    首先从第一个数据块中取出42页到50页的数据

    取出数据后保存在一个List<Product> firstProductList;

    2.    从第二个数据块中取出从51页到54页(如果第二个数据块在缓存不存在,就去数据库中取501-1000条,然后再放在缓存的第二个数据块中)。

    保存在第二个List<Product> secondProductList

    3. 然后把两个list合并,返回结果。例如

      secondProductList.Foreach(u=>firstProductList.Add(u));

  基本的实现就是这样,看起来还行,也比较的合理,但是就是因为这个操作,从而导致服务器内存溢出。

  大家想想看是什么原因。

  细节的重要性

  其实缓存的数据不是很多,是不足以让服务器内存溢出的,但是服务器还是出现了out of memory的异常。之前一直跑的很好,就是改了代码之后才出现问题的。

  其实这就是由于一个最基本的错误产生的:引用类型。

  下面就来分析下:

  首先是从第一个数据块中取出数据,然后用

    List<Product> firstProductList 引用指向取出的数据

  然后从第二个数据块中取出数据,用

    List<Product> secondProductList指向数据的引用

  如下图

 

  在第三步中采用

    secondProductList.Foreach(u=>firstProductList.Add(u));

  把secondProductList中的数据加入到firstProductList中,就因为是引用类型,其实实际操作的结果是:不断的在改变第一个数据块中的数据,使得第一个数据块中的数据逐渐的变多。

  现在当前页是48页,采用上面的操作,致使第一个数据块中的数据增加了60条,

  如果用户再次翻页,到了49页,那么第一个数据块中的数据又增多了60条

  依此类推,最后导致了服务器内存的不足,致使服务器崩溃了。原本的“功臣”----缓存却成为了罪魁祸首。

  其实这个问题的解决,只要改变一点点的代码就行了:

    List<Product> firstProductList;

    List<Product> secondProductList;

  然后

  List<Product> resultProductList=new List<Product>();然后分别把firstProductList,secondProductList遍历,加入到resultProductList就行了。

就这么简单。

  一个小的细节,导致了大的问题。

 

  不要忽视每一个细节。不要做没有比较的循环等操作,一定要审视代码,重构代码。

  今天就写到了这里,啰嗦了这么多,希望对大家有一点点的帮助。

  如有不正确,或者认为不妥的地方,希望大家斧正!而且留下高见!谢谢!

 

版权为小洋和博客园所有,欢迎转载,转载请标明出处给作者。

   http://www.cnblogs.com/yanyangtian

【原创】构建高性能ASP.NET站点之三 细节决定成败的更多相关文章

  1. 【原创】构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优(下前篇)—简单的优化措施

    原文:[原创]构建高性能ASP.NET站点 第六章-性能瓶颈诊断与初步调优(下前篇)-简单的优化措施 构建高性能ASP.NET站点 第六章—性能瓶颈诊断与初步调优(下前篇)—简单的优化措施 前言:本篇 ...

  2. 【原创】构建高性能ASP.NET站点 第五章—性能调优综述(后篇)

    原文:[原创]构建高性能ASP.NET站点 第五章-性能调优综述(后篇) 构建高性能ASP.NET站点 第五章—性能调优综述(后篇) 前言:本篇主要讲述如何根据一些简单的工具和简单的现象来粗布的定位站 ...

  3. 【原创】构建高性能ASP.NET站点之二 优化HTTP请求(前端)

    原文:[原创]构建高性能ASP.NET站点之二 优化HTTP请求(前端) 构建高性能ASP.NET站点之二 优化HTTP请求(前端) 前言: 这段时间比较的忙,文章写不是很勤,希望大家谅解. 上一篇文 ...

  4. 【原创】构建高性能ASP.NET站点之一 剖析页面的处理过程(前端)

    原文:[原创]构建高性能ASP.NET站点之一 剖析页面的处理过程(前端) 构建高性能ASP.NET站点之一 剖析页面的处理过程(前端) 前言:在对ASP.NET网站进行优化的时候,往往不是只是懂得A ...

  5. 【原创】构建高性能ASP.NET站点 开篇

    原文:[原创]构建高性能ASP.NET站点 开篇 构建高性能ASP.NET站点 开篇 前言:有段时间没有写ASP.NET的东西了,心里总是觉得缺少了什么,毕竟自己对ASP.NET还是情有独钟的. 在本 ...

  6. 【原创】构建高性能ASP.NET站点 第七章 如何解决内存的问题(前中篇)—托管资源优化—监测CLR性能

    原文:[原创]构建高性能ASP.NET站点 第七章 如何解决内存的问题(前中篇)-托管资源优化-监测CLR性能 构建高性能ASP.NET站点 第七章 如何解决内存的问题(前中篇)—托管资源优化—监测C ...

  7. 优化HTTP前端请求构建高性能ASP.NET站点

    HTTP请求的优化  在一个网页的请求过程中,其实整个页面的html结构(就是页面的那些html骨架)请求的时间是很短的,一般是占整个页面的请求时间的10%-20%.在页面加载的其余的时间实际上就是在 ...

  8. 【推荐】【给中高级开发者】构建高性能ASP.NET应用的几点建议

    本篇目录 早期阶段就要对应用进行负载测试 使用高性能类库 你的应用是CPU密集还是IO密集的 使用基于Task的异步模型,但要慎重 分发缓存和会话(session)状态 创建Web Gardens 巧 ...

  9. [转]【转】大型高性能ASP.NET系统架构设计

    大型高性能ASP.NET系统架构设计 大型动态应用系统平台主要是针对于大流量.高并发网站建立的底层系统架构.大型网站的运行需要一个可靠.安全.可扩展.易维护的应用系统平台做为支撑,以保证网站应用的平稳 ...

随机推荐

  1. 项目中那些事|ListView中嵌套ListView问题

    要在一个ListView中放入另一个ListView,也即在一个ListView的每个 item 中放入另外一个ListView.但刚开始的时候,会发现放入的子ListView会显示不完全(我这里只显 ...

  2. MySQL的一些基本操作

    近期開始学习MySQL,主要是通过书籍,和看燕十八老师的视频,然后通过博客记录自己的学习过程. 登入数据库 zhiniaobu@telunsu-K55VD:~$ mysql -uroot -p Ent ...

  3. 飘逸的python - __new__、__init__、__call__傻傻分不清

    __new__: 对象的创建,是一个静态方法.第一个參数是cls.(想想也是,不可能是self,对象还没创建,哪来的self) __init__ : 对象的初始化, 是一个实例方法,第一个參数是sel ...

  4. css 背景色渐变

    background:rgba(0, 0, 0, 0) linear-gradient(to bottom, #eff5ff 0px, #e0ecff 20%) repeat-x scroll 0 0 ...

  5. 消息队列(Message Queue)基本概念(转)

    背景 之前做日志收集模块时,用到flume.另外也有的方案,集成kafaka来提升系统可扩展性,其中涉及到消息队列当时自己并不清楚为什么要使用消息队列.而在我自己提出的原始日志采集方案中不适用消息队列 ...

  6. 黄聪:Microsoft Enterprise Library 5.0 系列教程(一) Caching Application Block (高级)

    原文:黄聪:Microsoft Enterprise Library 5.0 系列教程(一) Caching Application Block (高级) Caching Application Bl ...

  7. windows phone (15) UI变换上

    原文:windows phone (15) UI变换上 在wp中只要是继承自UIElement 的任何对象都可以应用变换,当然包含Textblock,Rectangle等所有的元素,下面我们使用Tex ...

  8. python学习之list

    list: 创建:list = [5,7,9] 取值和改值:list[1] = list[1] * 5 列表尾插入:list.append(4) 去掉第0个值并返回第0个值的数值:list.pop(0 ...

  9. 经典排序算法 - 高速排序Quick sort

    经典排序算法 - 高速排序Quick sort 原理,通过一趟扫描将要排序的数据切割成独立的两部分,当中一部分的全部数据都比另外一部分的全部数据都要小,然后再按此方法对这两部分数据分别进行高速排序,整 ...

  10. MVC Controller向View传值(ViewData与ViewBag)

    近期在开发项目中,使用的是ASP.NET MVC因为之前并没有接触,对于它的传值方式有些陌生,在这里进行初步总结积累学习. 一:使用 ViewData使用: public ActionResult I ...