客服电话
APP下载
迪恩网络APP
随时随地掌握行业动态
官方微信
扫描二维码
关注迪恩网络微信公众号
|
构建高性能ASP.NET站点 开篇
前言:有段时间没有写ASP.NET的东西了,心里总是觉得缺少了什么,毕竟自己对ASP.NET还是情有独钟的. 在本系列文章中,准备比较全面的讲述ASP.NET的性能的优化,从前台到后台,以后本列文也看作为大家的一个手册来查询!
本篇的议题如下: 网站优化需要考虑的方面
网站优化需要考虑的方面
在用ASP.NET开发网站的时候,性能是永远需要考虑和关注的问题,性能不仅仅只是程序代码执行时候的速度，而是涉及到方方面面的东西。
就拿ASP.NET的一个请求来讲，从浏览器向服务器的ASP.NET网站发送请求开始一直到最后整个页面呈现在我们面前，其中请求经过的每一个步骤，都是有不同的调优方式的，而且调用的方法也很多，不仅仅只是常见的：缓存，多线程，异步等。
本系列的文章决定从两个大的方面来讲述调优： 前台调优：主要包含如何尽量的减少http请求，从http请求开始，到如何加载js, css，如何压缩传输的数据等。
后台调优：分析ASP.NET请求的处理过程，并在每一步给出相应的调优方法，而且在代码组织，架构和数据库的操作上面给出调优的方法。
记得在刚刚开发网站的时候，一提到提高性能，最容易也是最快想到的就是缓存，而且在微软官方的Best Practice的一些文档中也是建议：层层缓存(在数据存储层，DAL,BLL,UI等都要缓存)。然后在网站中就”缓存遍地开花”，最后的确实不尽人意。
另外的一个常见的优化针对数据库的：如尽量减少子查询，使用join联接；在常常需要查询的字段上面建立索引。确实，这些是很通用，也不错的一些规则。
而且还有一个体会就是，在优化性能的时候，如果选择优化代码和数据库，往往优化数据库的一些操作带来的效果会更加的好，很可惜的是：在项目中(至少在我开发的一些项目中)，数据库仅仅就只是一个数据的存储设备而已，仅此而已，没有发挥出数据库的强大作用。所以还是建议对数据库的内部查询和存储的机制要熟悉，毕竟很多时候开发人员也担任了DBA的工作（很多公司没有正式的DBA）。
而且在项目中我们设计数据库的时候，特别是表字段的时候，是需要有些考虑的，很多人建议表字段的长度不要太长，这也是大家常见的建议，但是为什么？其实，这就需要懂得一些数据库的内部存储机制了：在数据库(SQL SERVER )保存的时候，数据是以”页”为最小的单位的，每一页有8K的大小，如果你的一个表中的数据超过8K，那么这个表的数据就要分几个页面保存，这样在对数据进行查询的时候，就要跨页查询了，跨页是需要性能消耗的，如果数据都在一个页面上，那么速度肯定快些。
所以，要优化网站，就得知道性能消耗在哪里。
当优化的一个网站的时候，不是盲目的一概而论的，一般来说有两种情况： 1． 网站已经存在了，并且运行了，现在要优化。 2． 正在从头开发一个新的网站。
如果是第一种情况，那么首先要找出网站性能的瓶颈，从前台的请求的到后台的请求处理，一直到最后页面的呈现，都要一步步的审查。
如果是第二种情况，可能情况就稍微好一点，并且网站现在完全由我们控制，所有在开发和设计的过程中就可以采用很多的优化原则来优化。
优化不一定就是代码重写或者做些很大的改动，优化时一点点的累积的，就好比代码的重构一样，都是一个积累的效果。比如，是在页面一开始的时候载入js脚本，还是在整个页面的最后载入js脚本，有时候往往就只是简单的调整一下载入的文件，或者异步的载入脚本，或者通过CDN传输脚本等等方法，性能就提升了。性能的提升也不是没有代价的，有的代价很小，例如只是把脚本的载入放在页面最后，大的代价就是，例如买些服务器设备，如Content Delivery Network(CDN)来把静态的文件(js,css,image)传送到客户端。所以说，优化需要权衡策略。
不知道大家是否有过这样的体会：当看着自己开发出来的系统性能很好的时候，自己是很自信的，相反，如果系统很慢，有时真不想说这个系统是自己做的。
本篇是系列开篇，只是闲谈了一些优化的一些话题，实际的知识没有讲多少，希望大家见谅。 下篇开始，我们就开始优化之旅，敬请关注！ ：）
版权为小洋和博客园所有，欢迎转载，转载请标明出处给作者。 http://www.cnblogs.com/yanyangtian
|
请发表评论