外贸网站 测速,网站建设渠道员,网页版游戏排行榜传奇,设计企业网店推广策略如果你在构建一个面向公众的web站点#xff0c;那么在项目结尾时你想要实现的就是web负载性能良好。这意味着#xff0c;你要确保你的产品在高负载下#xff08;50个并发用户或者每秒200个用户等等#xff09;能够运行#xff0c;即使你认为此时不会有那么大的负载。久而久… 如果你在构建一个面向公众的web站点那么在项目结尾时你想要实现的就是web负载性能良好。这意味着你要确保你的产品在高负载下50个并发用户或者每秒200个用户等等能够运行即使你认为此时不会有那么大的负载。久而久之你的web站点可能吸引越来越多的用户此时如果web的负载难以让人忍受时那么自然而然网站开始走下坡路意味着客户流失以及名誉受损。 那么可以采取哪些措施可以使得一个ASP.NET或者ASP.NET MVC应用更加高性能呢 早期阶段就要对应用进行负载测试 大多数开发者趋向在应用开发完成后集成测试和回归测试通过后才进行负载测试。尽管在开发完成后执行一次负载测试好过不做但是一旦完成了代码的编写修复性能问题就为时已晚了。这个问题最常见的例子就是当应用程序在负载测试时不能正确响应时就会考虑向外扩展增加更多的服务器。有时这是不可能的因为代码不适合实现扩展服务器。比如当对象是存储在Session中并不可序列化时这样添加更多的web节点或者工作者进程就是不可能的。如果你在开发的早期阶段就发现你的应用可能要部署到多台服务器上那么你应该在配置和服务器的数量等方面都要让测试环境和最终环境尽可能地接近这样你的代码会更容易适应。 使用高性能类库 近来我在诊断web站点的性能问题时发现了代码中的一个热点问题来自第三方web服务的JSON信息必须要被反序列化多次。那些Json信息是由Newtonsoft.Json反序列化的并且证明了Newtonsoft.Json在反序列化时不是最快的类库然后我们使用了一个更快的类库如ServiceStack替代了Json.Net并获得了更好的结果。 如果我们在挑选了Json.Net作为序列化类库的早期阶段就完成了负载测试那么我们就会更早地发现性能问题我们就不必再代码中做这么多的修改了也不必再次完整地重新测试了。 你的应用是CPU密集还是IO密集的 在开始实现web应用以及设计项目时你要首先考虑的一件事就是你的应用是CPU密集的还是IO密集的这对于了解扩展应用的策略是很重要的。 比如如果你的应用是CPU密集的那么你可能想使用同步模式并行处理等等。然而对于一个有很多IO受限的操作例如和外部web服务或者网络资源如数据库通讯的产品基于Task的异步模式可能对于向外扩展更有帮助。此外为了在未来的某天能够创建Web Gardens和Web Farms,你可能想有一个集中式的缓存系统这样就实现了跨越多个工作者进程或服务的负载。 使用基于Task的异步模型但要慎重 如果你的产品依赖许多IO受限的操作或者包括了可能需要消耗宝贵的IIS线程等待一个操作完成的长时间运行的操作你最好为ASP.NET MVC项目考虑使用基于Task的异步模式。 互联网上有很多关于异步的ASP.NET MVC actions的手册比如这个所以这篇博客尽量避免介绍关于异步的知识点。然而必须指出ASP.NET (MVC)中传统的同步action会造成IIS线程繁忙直到操作完成或请求处理完成。这意味着如果如果web应用在等待一个外部的资源如一个web服务响应那么该线程将是繁忙的。.Net线程池中可以用于处理请求的线程数量也是有限的因此尽可能快地释放线程是很重要的。基于Task的异步action或方法会在请求处理后释放该线程然后从线程池中获取新的线程并使用该新的线程返回该action的结果。这样多个请求可以由多个线程处理这会为你的应用带来更好的响应。 虽然TAP模式对于适当的应用来说很方便但必须要慎重使用。当你使用TAP设计或者实现一个项目时必须要注意几个点你可以点击这里查看然而开发者使用async和await关键字面临的最大挑战是知道在这个上下文中他们必须略有不同地处理线程。比如可以创建一个返回Task如Task《Product》,博客园的markdown不支持单尖括号的方法通常你可以对那个Task调用Run()方法或者只调用task.Result来迫使运行该task,直到拿到结果。 分发缓存和会话session状态 开发者在单个开发机器上构建一个web应用是非常常见的并且也会假设该产品运行在单个服务器上然而对于面向大众的web通常不是这样的。它们往往被部署到一个叫做负载均衡之后的多个服务器上。尽管你仍然可以使用In-Proc关于In-Proc和Out-Proc的知识点补充的模式和粘性stickySession将一个web应用部署到多个服务器上负载均衡器会将属于相同session的所有请求定向到单个服务器你可能必须保留session数据和缓存数据的多个副本。比如如果你将产品部署到由4台服务器组成的web farm上并且你保持session数据为In-Proc,那时一个请求到达一个已经包含缓存数据的机会是四分之一或25%然而你如果在正确的地方使用了集中式缓存机制那么为每个请求找到缓存条目的机会就是100%。这对于严重依赖缓存数据的web应用是至关重要的。 使用集中式缓存机制像App Fabric或Redis的另一个好处是对实际的产品实现主动缓存系统的能力。主动缓存机制可以用于在客户端请求一个条目之前就可以将最受欢迎的条目预加载到缓存中。如果你使用实际的数据源来管理缓存同步时那么这会帮助你大幅地改善大数据驱动应用的性能。 创建Web Gardens 之前提到在一个IO受限的web应用中包含了很多长时间运行的操作如web服务的调用此时你可能想尽可能地释放主线程。默认情况下每个web应用运行在一个主线程下该主线程为保持web站点存活alive负责但不幸的是当它太忙的时候你的站点就变得不能响应了。给应用添加更多的“主线程”是一种办法这是通过将更多的工作者进程添加到IIS下的Web站点来实现的。每个工作者进程都会包括一个单独的主线程因此如果一个主线程繁忙还有另外的主线程来处理到来的请求。 拥有多个工作者进程会将你的web站点变成一个Web Garden这要求你将Session和应用数据持久化到Out-Proc中例如一个state server或者Sql Server。 巧妙地使用缓存和懒加载 无需强调如果你将经常访问的一点数据缓存到内存中那么这会减少数据库和web服务的调用。正如之前所说这对于IO受限的应用特别有帮助当网站处于低负载时可能会造成不幸。 提高站点响应的另一种方式是使用懒加载。懒加载意味着应用里不会有确定的数据片但是它知道数据在哪里。比如如果web页面上有一个下拉列表这意味着要显示一个产品列表一旦页面加载完毕不必从数据库中加载所有的产品。你可以在页面中添加一个jQuery函数该函数可以在第一次下拉时填充下拉列表。你也可以在代码中的许多地方使用相同的技术比如当使用Linq查询和CLR集合时。 不要在MVC视图中放C#代码 ASP.NET MVC视图会在运行时编译而不是在编译时因此如果在视图中包含了太多的C#代码那么你的代码不会编译后放到dll文件中。这样做不仅有害于软件的可测试性还会使web应用更慢因为每个页面都有花更长的时间获得显示因为它们必须被编译。将代码添加到视图中的其他缺陷在于它们不能异步运行这样如果你决定基于TAP来构建应用时就不能充分利用视图中的异步方法和action了。 比如如果你的代码中有这么一个方法 public async Taskstring GetName(int code){ var result … return await result;} 该方法可以在一个异步的ASP.NET MVC action的上下文中异步运行比如 public TaskActionResult Index( CancellationToken ctx ){ var name await GetName( 100 );
} 但是如果在一个视图中调用这方法因为该视图不是异步的所以必须以一种线程阻塞(thread-blocking)的方式运行如 var name GetName(100).Result; .Result会阻塞运行的线程直到GetName()处理完成了请求这样该应用的执行会停止一会儿然而当使用await关键字调用该代码时该线程不会被阻塞。 适当时使用Fire Forget 注Fire Forget字面意思是发射然后忘记不去理会了。网络释义为射后不理。如果两个或多个操作没有生成单个事务那么你很可能不必按顺序运行它们。比如如果一个用户在你的站点注册时创建了一个账户一旦他们注册了你就把他们的详细信息保存到数据库然后给他们发送一封邮件你不必等待邮件发送出去才结束这个操作。 在这种情况下最好的方法很可能就是开启一个新的线程让它给用户发送邮件然后返回到主线程。这就叫做Fire Forget它可以提高应用的响应能力。 为x64 CPU创建 32-bit的应用局限于较低的内存量和可以访问更少的CPU功能/指令。要克服这些限制如果你的服务器是64-bit的那么要确保你的应用运行在64-bit模式下通过确保在IIS的32-bit模式下运行网站的选项是不是开启。然后为x64 CPU编译并生成代码而不是Any CPU。 x64有用的一个例子是提高数据驱动应用的响应能力和性能有一个好的缓存机制是必须的。In-proc是消耗内存的因为一切都存储在网站的应用程序池的内存边界。对于x86进程来说可以分配的内存量限制到4GB这样如果加载到缓存中这个限制很快就被打破。如果相同的站点是为x64 CPU显式生成的那么内存限制就不需考虑了这样更多的条目可以加到缓存中然后和数据库的通讯就少了这会带来更好的性能。 使用服务器上的监视和诊断工具 可能存在你肉眼看不到的更多的性能问题因为它们不会出现在错误日志中。当应用程序已经部署到基本没有机会调试的服务器上时识别性能问题是更吓人的事情。 要找出缓慢的处理线程阻塞悬挂错误等等强烈建议在服务器上安装一个监视和诊断工具让它们持续地跟踪和监视你的应用程序。我个人使用的是NewRelic检查我的在线网站的健康。获取详细信息并创建免费账号看这里哦 分析运行中的应用 一旦完成了网站开发部署到IIS然后附加一个分析器如Visual Studio Profiler然后抓取应用的多个部分的快照。比如抓取购买或者用户注册等操作的快照然后检查病查看是否存在任何造成缓慢或阻塞的代码。在早期阶段找到那些热点可能会节省你大量的时间荣誉和金钱。 原文地址http://www.cnblogs.com/farb/p/AspNetAppWithHighPerformance.html .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
