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

简介: 原文:【原创】构建高性能ASP.NET站点之三 细节决定成败构建高性能ASP.NET站点之三 细节决定成败     前言:曾经就因为一个小小的疏忽,从而导致了服务器崩溃了,后来才发现:原来就是因为一个循环而导致的,所以,对“注意细节“这一说法是深有感触。
原文: 【原创】构建高性能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

 

目录
相关文章
|
存储 Shell Linux
快速上手基于 BaGet 的脚本自动化构建 .net 应用打包
本文介绍了如何使用脚本自动化构建 `.net` 应用的 `nuget` 包并推送到指定服务仓库。首先概述了 `BaGet`——一个开源、轻量级且高性能的 `NuGet` 服务器,支持多种存储后端及配置选项。接着详细描述了 `BaGet` 的安装、配置及使用方法,并提供了 `PowerShell` 和 `Bash` 脚本实例,用于自动化推送 `.nupkg` 文件。最后总结了 `BaGet` 的优势及其在实际部署中的便捷性。
1126 10
|
JSON 编解码 API
Go语言网络编程:使用 net/http 构建 RESTful API
本章介绍如何使用 Go 语言的 `net/http` 标准库构建 RESTful API。内容涵盖 RESTful API 的基本概念及规范,包括 GET、POST、PUT 和 DELETE 方法的实现。通过定义用户数据结构和模拟数据库,逐步实现获取用户列表、创建用户、更新用户、删除用户的 HTTP 路由处理函数。同时提供辅助函数用于路径参数解析,并展示如何设置路由器启动服务。最后通过 curl 或 Postman 测试接口功能。章节总结了路由分发、JSON 编解码、方法区分、并发安全管理和路径参数解析等关键点,为更复杂需求推荐第三方框架如 Gin、Echo 和 Chi。
|
前端开发 C# 开发者
.NET使用Umbraco CMS快速构建一个属于自己的内容管理系统
.NET使用Umbraco CMS快速构建一个属于自己的内容管理系统
400 12
|
弹性计算 开发框架 安全
基于云效 Windows 构建环境和 Nuget 制品仓库进行 .Net 应用开发
本文将基于云效 Flow 流水线 Windows 构建环境和云效 Packages Nuget 制品仓库手把手教你如何开发并部署一个 .NET 应用,从环境搭建到实战应用发布的详细教程,帮助你掌握 .NET 开发的核心技能。
|
Kubernetes Cloud Native Ubuntu
庆祝 .NET 9 正式版发布与 Dapr 从 CNCF 毕业:构建高效云原生应用的最佳实践
2024年11月13日,.NET 9 正式版发布,Dapr 从 CNCF 毕业,标志着云原生技术的成熟。本文介绍如何使用 .NET 9 Aspire、Dapr 1.14.4、Kubernetes 1.31.0/Containerd 1.7.14、Ubuntu Server 24.04 LTS 和 Podman 5.3.0-rc3 构建高效、可靠的云原生应用。涵盖环境准备、应用开发、Dapr 集成、容器化和 Kubernetes 部署等内容。
1056 6
|
C# Windows 开发者
超越选择焦虑:深入解析WinForms、WPF与UWP——谁才是打造顶级.NET桌面应用的终极利器?从开发效率到视觉享受,全面解读三大框架优劣,助你精准匹配项目需求,构建完美桌面应用生态系统
【8月更文挑战第31天】.NET框架为开发者提供了多种桌面应用开发选项,包括WinForms、WPF和UWP。WinForms简单易用,适合快速开发基本应用;WPF提供强大的UI设计工具和丰富的视觉体验,支持XAML,易于实现复杂布局;UWP专为Windows 10设计,支持多设备,充分利用现代硬件特性。本文通过示例代码详细介绍这三种框架的特点,帮助读者根据项目需求做出明智选择。以下是各框架的简单示例代码,便于理解其基本用法。
1524 0
|
Java Spring 自然语言处理
Spring 框架里竟藏着神秘魔法?国际化与本地化的奇妙之旅等你来揭开谜底!
【8月更文挑战第31天】在软件开发中,国际化(I18N)与本地化(L10N)对于满足不同地区用户需求至关重要。Spring框架提供了强大支持,利用资源文件和`MessageSource`实现多语言文本管理。通过配置日期格式和货币符号,进一步完善本地化功能。合理应用这些特性,可显著提升应用的多地区适应性和用户体验。
403 0
|
开发框架 前端开发 .NET
ASP.NET CORE 3.1 MVC“指定的网络名不再可用\企图在不存在的网络连接上进行操作”的问题解决过程
ASP.NET CORE 3.1 MVC“指定的网络名不再可用\企图在不存在的网络连接上进行操作”的问题解决过程
1075 0
|
存储 开发框架 前端开发
[回馈]ASP.NET Core MVC开发实战之商城系统(五)
经过一段时间的准备,新的一期【ASP.NET Core MVC开发实战之商城系统】已经开始,在之前的文章中,讲解了商城系统的整体功能设计,页面布局设计,环境搭建,系统配置,及首页【商品类型,banner条,友情链接,降价促销,新品爆款】,商品列表页面,商品详情等功能的开发,今天继续讲解购物车功能开发,仅供学习分享使用,如有不足之处,还请指正。
715 0
|
开发框架 前端开发 JavaScript
ASP.NET MVC 教程
ASP.NET 是一个使用 HTML、CSS、JavaScript 和服务器脚本创建网页和网站的开发框架。
599 7