摘要: ASP.NET几种清除页面缓存的方法在asp.net中使用模式dialog时,你会发现每次打开的页面都是相同的内容,页面内容并没有刷新,这是缓存的原因造成的,解决方法如下:第一种是ASP.NET清除页面缓存 Response.Buffer = true; Response.ExpiresAbsolute = System.DateTime.Now.AddSeconds(-1); Response.Expires = 0; Response.CacheControl = "no-cache"; Response.AddHeader("Pragma", &q 阅读全文
posted @ 2012-12-12 17:33 SunShineTian 阅读(235) 评论(0) 推荐(0) 编辑
摘要: 在JS中判断浏览器的类型,估计是每个编辑过页面的开发人员都遇到过的问题。在众多的浏览器产品中,IE、Firefox、Opera、Safari........众多品牌却标准不一,因此时常需要根据不同的浏览器,甚至相同浏览器不同版本做不同的操作,因此,知晓浏览器的判断方法,还是很重要的。下面列举一下常用的判断方法:1、判断浏览器是否为IE document.all ? 'IE' : 'others':在IE下document.all值为1,而其他浏览器下的值为0; navigator.userAgent.indexOf("MSIE")>0 阅读全文
posted @ 2012-05-28 09:11 SunShineTian 阅读(257) 评论(0) 推荐(0) 编辑
摘要: 出处:http://www.jb51.net/article/25981.htm1.静态加载 CSS,图片资源文件在页面渲染过程中可以并行下载,不会阻塞。在IE8,FF下,也可以支持JS的并行下载。尽管页面的JS下载加速了,但是JS对页面渲染的阻塞还是依然存在的,只有JS加载完毕了,页面的剩余部分才能继续渲染。放在Head部分的Script是最为恶劣的,因为对页面来说,Head部分是require的,是后部分所必须的,Head部分不加载完毕,Body部分不会开始解析,Body解析之前,页面是空白的。静态Script放到页面的哪部分来说都是阻塞,从浏览器实现的角度来说很好理解,因为JS代码中完全 阅读全文
posted @ 2012-05-23 22:49 SunShineTian 阅读(226) 评论(0) 推荐(1) 编辑
摘要: JSON是一种便于操作使用的轻量级数据交换格式。易于人阅读和编写。同时也易于机器解析和生成。很多时候我们需要将JSON格式的字符串转化为JSON对象或者将JSON对象转为JSON字符串。特别是在AJAX应用中经常需要将JSON格式的字符串返回到前端,前端解析成js对象(JSON )。现将工作中接触到的一些方法总结如下:。一. 将JSON字符串转化为JSON对象eval方式解析。各个版本的浏览器都支持,也是以前最早使用的方式了,而且性能也不错。使用方法为:eval('('+sJSON+')') ;注意:在字符串两端再加上括号,否则会出错。有时从数据库读出来的数据带 阅读全文
posted @ 2012-05-19 22:48 SunShineTian 阅读(3770) 评论(0) 推荐(1) 编辑
摘要: 《ASP.NET 本质论》HttpApplication的处理管道 原文:http://blog.csdn.net/sky1069/article/details/6659667HttpApplication对象是ASP.NET中处理请求的重要对象,但是,这种类型的对象实例不是由程序员来创建的,而是由ASP.NET帮助我们创建的。为了便于扩展处理工作,HttpApplication采用处理管道的方法进行处理,将处理的过程分为多个步骤,每个步骤通过事件的形式暴露给程序域,这些事件按照固定的处理顺序依次触发,程序员通过编写事件处理方法就可以自定义每一个请求的扩展处理过程。 对于HttpAppli. 阅读全文
posted @ 2012-05-10 00:44 SunShineTian 阅读(488) 评论(0) 推荐(0) 编辑
摘要: 原文:http://fsh430623.iteye.com/blog/715981时常看到高并发的问题,但高并发其实是最不需要考虑的东西。为何,他虚无缥缈,很少有网站真的需要这些东西,而且其中很多技术,其实你已经在用了。有这个意识就够了,不需要时刻盯着这个问题。只有很少的网站真的能达到高并发。 简单做一个归纳,从低成本、高性能和高扩张性的角度来说有如下处理方案: 1、HTML静态化 2、图片服务器分离 3、数据库集群和库表散列 4、缓存 5、镜像 6、负载均衡;一个典型的使用负载均衡的策略就是,在软件或者硬件四层交换的基础上搭建squid集群,这种思路在很多大型网站包括搜索引擎上被... 阅读全文
posted @ 2012-05-08 19:06 SunShineTian 阅读(1411) 评论(0) 推荐(0) 编辑
摘要: SQL SERVER性能优化综述一个系统的性能的提高,不单单是试运行或者维护阶段的性能调优的任务,也不单单是开发阶段的事情,而是在整个软件生命周期都需要注意,进行有效工作才能达到的。所以我希望按照软件生命周期的不同阶段来总结数据库性能优化相关的注意事项。一、分析阶段 一般来说,在系统分析阶段往往有太多需要关注的地方,系统各种功能性、可用性、可靠性、安全性需求往往吸引了我们大部分的注意力,但是,我们必须注意,性能是很重要的非功能性需求,必须根据系统的特点确定其实时性需求、响应时间的需求、硬件的配置等。最好能有各种需求的量化的指标。 另一方面,在分析阶段应该根据各种需求区分出系统的类型,大的方面, 阅读全文
posted @ 2012-05-08 19:05 SunShineTian 阅读(200) 评论(0) 推荐(0) 编辑
摘要: MSSQL Server 查询优化方法 整理详细出处参考:http://www.jb51.net/article/22798.htm查询速度慢的原因很多,常见如下几种1、没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷) 2、I/O吞吐量小,形成了瓶颈效应。 3、没有 创建计算列导致查询不优化。 4、内存不足 5、网络速度慢 6、查询出的数据量过大(可以采用多次查询,其他的方法降低数据量) 7、 锁或者死锁(这也是查询慢最常见的问题,是程序设计的缺陷)sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。 9、返回了不必 要的行和列 10、查询语句不好,没有优化 阅读全文
posted @ 2012-05-08 19:01 SunShineTian 阅读(202) 评论(0) 推荐(0) 编辑
摘要: SQLServer 优化SQL语句 in 和not in的替代方案详细出处参考:http://www.jb51.net/article/23293.htm用IN写出来的SQL的优点是比较容易写及清晰易懂,这比较适合现代软件开发的风格。但是用IN的SQL性能总是比较低的,从SQL执行的步骤来分析用IN的SQL与不用IN的SQL有以下区别: SQL试图将其转换成多个表的连接,如果转换不成功则先执行IN里面的子查询,再查询外层的表记录,如果转换成功则直接采用多个表的连接方式查询。由此可见用IN的SQL至少多了一个转换的过程。一般的SQL都可以转换成功,但对于含有分组统计等方面的SQL就不能转换了。 阅读全文
posted @ 2012-05-08 18:59 SunShineTian 阅读(651) 评论(0) 推荐(0) 编辑
摘要: SQL SERVER 的SQL语句优化方式小结详细出处参考:http://www.jb51.net/article/19547.htm1、SQL SERVER 2005的性能工具中有SQL Server Profiler和数据库引擎优化顾问,极好的东东,必须熟练使用。2、查询SQL语句时打开“显示估计的执行计划”,分析每个步骤的情况3、初级做法,在CPU占用率高的时候,打开SQL Server Profiler运行,将跑下来的数据存到文件中,然后打开数据库引擎优化顾问调用那个文件进行分析,由SQL SERVER提供索引优化建议。采纳它的INDEX索引优化部分。4、但上面的做法经常不会跑出你所需 阅读全文
posted @ 2012-05-08 18:56 SunShineTian 阅读(225) 评论(0) 推荐(0) 编辑