qq空间网站是多少,怎么把网站排名排上去,烟台做网站价格,企业网站建设问题这篇文章是关于网站性能优化体验的#xff0c;性能优化是一个复杂的话题#xff0c;牵涉的东西非常多#xff0c;我只是按照我的理解列出了性能优化整个过程中需要考虑的种种因素。点到为止#xff0c;包含的内容以浅显的介绍为主#xff0c;如果你有见解能告知我那再好不…这篇文章是关于网站性能优化体验的性能优化是一个复杂的话题牵涉的东西非常多我只是按照我的理解列出了性能优化整个过程中需要考虑的种种因素。点到为止包含的内容以浅显的介绍为主如果你有见解能告知我那再好不过了。无论如何希望阅读它的你有所收获。 我眼中的网站性能问题都反映了一个网站的“Availability”中文叫做可用性但是这个翻译也不足够达意以往我的认识是这个网站如果全部或者部分不可用那是功能问题但是如果响应慢、负载差这才是性能问题可是后来我逐渐意识到性能问题涵盖的范围更广我还没法给出一个准确定义但是许多非业务逻辑错误引起的网站问题都可能可以算做性能问题比如可扩展性差比如单点故障问题。 在网站性能优化的最初阶段也就是所谓的“第一重境界”做局部的定位、分析和修正考虑的仅仅是“优化”这也是初涉性能优化问题的大多数人的认识。在问题发生以后发现它和业务逻辑没有太大关系就开始尝试寻找问题产生的原因并加以解决。 无论是网站无响应还是响应缓慢还是响应曲线异常波动比如可以围绕CPU的使用问自己这样几个问题 从CPU使用看系统是否繁忙如果系统繁忙系统在做什么为什么典型问题HashMap不安全并发导致的死循环如果系统空闲那么瓶颈在哪里典型问题IO无响应如果响应波动是否存在周期周期是什么典型问题连接迅速占满每一周期批量超时断开一批如果响应波动性能到波谷时系统在做什么是否有背景CPU使用即无压力下观察CPU的使用情况。典型问题正执行的定时任务占用过多系统资源
在这些问题中情况虽然千变万化简单地说CPU的使用是核心CPU使用率高说明可能系统在实实在在地做事反之需要寻找其他瓶颈。通过结合进程、线程的快照来初步确定问题的范围。CPU使用率低的情况居多而且容易定位只需要寻找其他的系统瓶颈CPU占用率偏高的问题往往比较不容易定位虽然也有一些办法。关于具体性能问题的定位技术这里不着过多笔墨后续有机会详细介绍。 对于一个刚开始做性能优化的网站系统下面的事情不妨都做一做会有立竿见影的效果如果你需要更多的建议不妨参考这张图 对于使用的成熟的技术技术社区、官方文档往往会给出这种技术的白皮书或者优化指导请参考。比如 Struts2的官方性能调优指南、Java6性能优化白皮书。平台和虚拟机调优。对于使用平台和虚拟机的项目来说这是必须要做的一个JVM的参数可以对系统有显著的影响。比如Linux下连接管理的参数JVM关于堆大小分布的参数等等。前端审查。这里的审查指的是通过Page speed、YSlow等工具以及一些业界通用的法则和经验比如yahoo的若干条前端性能优化法则来评估现有页面的问题。
从使用的工具上说性能问题的定位很大程度上是面向操作系统、虚拟机系统的问题定位这里有一些定位方法介绍。从问题定位的时机上说又可以分为 截取型截取系统某个层面的一个快照加以分析。比如一些堆栈切面和分析的工具jstack、jmap、kill -3、MAT、Heap Analyser等。监控型监视系统变化甚至数据流向。比如JProfiler、JConsole、JStat、BTrace等等。验尸型系统已经宕机了但是留下了一些“罪证”在事后来分析它们。最有名的就是JVM挂掉之后可能会留下的hs_err_pid.log或者是生成的crash dump文件。 好暂时说到这里下面来看第二重境界。达到这重境界意味着已经能够跳出“事后优化”的局限了在设计和编码的过程当中能够正式和全面地考虑性能的因素比如 减少使用时间敏感的容器管理而使用容量或数量敏感的容器管理。比如我往一个缓冲里面存放若干数据一种设计是每10分钟flush入库一次还有一种设计是数据到达10M大小的时候flush入库一次通常情况下你觉得哪个方案更可靠线程的统一管理使用。我的经验是10次对线程创建或者线程池的使用往往就有5次是会出问题的。避免使用同步Ajax。同步Ajax会造成浏览器假死直至响应返回。分析对同步、锁的使用。即便在一些有名的开源库中我们也不止一次发现过不合理的同步设计N多数据单一的全局同步块这是一种性能设计层面上的“中心化”结果它就成为了瓶颈改动还不容易下手很麻烦。
对于不成熟的团队建议能安排有经验的程序员把关设计文档和编码中的性能问题把常见的问题列出来参考学习。 达到第二重境界还有一个明显的特征就是在软件流程的前中期就开始做性能目标的论证和性能问题的验证 性能切面分析。这指的是在系统设计初期为了评估一个系统的性能表现做出一个性能类似的系统原型并对其做性能测试和评估这时候因为性能问题而涉及到方案的变更影响较小。据我所知能够做到这一点的项目极少。在大多数团队中依赖于架构师和掌握话语权的设计者依靠经验来避免性能问题带来的大的方案变更或者干脆摔一次跤再进行痛苦的“重构”。性能的自动化测试验证。这一步必须伴随着Coding进行才有较大的意义以便尽早发现性能问题。设计和代码层面的评审。我的博客里面一再地强调评审的价值不妨看看这篇和这篇。其实功能问题考虑得多、暴露得早真正有危险的往往都是那些被忽视的非功能性问题比如性能问题。 最后是第三重境界。达到这重境界的团队能够在早期规划构想阶段就将性能作为一个必备因素包含在内这可不是随口说说的经验的估计而是要有数据驱动的理论设计比如做性能建模根据市场大小、业务量、服务等级等等计算出性能的具体指标并且在此要求下做合理的架构设计。 这里涉及的东西有很多除了数据还需要有大量的思考对于一个网站来说不妨问问如下的问题 数据量会有多大我该设计什么样的存储一致性的要求又如何实时性要求是怎么样的用户可以接受多少时间的数据延迟网站需要考虑到什么程度的可伸缩性哪些流程的数据处理有性能风险数据量是什么级别的怎么解决这个问题主要的业务时间消耗是怎样的我需要设计怎样的业务流来满足
所有的性能问题和其他一切非功能性问题一样都是一定程度上的trade off所以越优秀的设计者越需要思考来规划这些问题的解决方案。在规划中因为性能问题而涉及到的因素有哪些太多太多了这里列了一些供参考。 要达到第三重境界还要能够预测性能问题。这就需要成熟的监控体系监控系统的变化尽快做出反应。 比如国内发生了重大事件用户量陡增监控系统能够及时识别出用户量监控曲线一个非常明显的跳跃过程比如持续事件超过某个值且曲线斜率超过某个值发出告警并且自动扩容来应付潜在的风险。这些都是建立在常规的业务运营数据收集基础之上的然后需要做数据挖掘给出关键点。 再比如互联网应用“缓存为王”。对于缓存的设计甚至很大程度上决定了应用的成败如果你很有钱靠大量的CDN这种非常规路线的另说呵呵。缓存的设计需要考虑到缓存的大小、分级、队列、命中率计算、生命周期、更新换页、数据分发、数据一致性和数据持久化等等问题这些东西往往被很多只重视那些页面展示效果和功能的人所忽视但如果你是优秀的设计者你需要积累这些思考。 Think big。有这样一个真实的例子我们曾经发现页面模板的OGNL性能不高两次反射之故遂在项目中把大部分OGNL表达式都改成了EL表达式花了很多时间精力性能也确实提高了但是能提高多少呢大概只有30%这是一种细水长流的改进对系统的破坏性不大但是收效也不足以令人沾沾自喜还失去了一些OGNL的灵活性。之后我们换了一个思路从大局入手给页面划分区域定制缓存框架引入页面缓存能力虽然整套方案有些复杂但是这种架构上的进化由于页面的生成或者部分生成直接命中了缓存文件性能一下有了飞跃提高了600%~800%。这就是Think big从大处着想见得到工程大块的结构需要足够的视野、足够的经验和积累可以带来显著的效果。 通常系统容量的设计都会要求到峰值容量以上如果是像秒杀、抢购之类对性能要求非常高的系统往往还存在一个问题设计了这么大的容量平时大部分时间业务量都比较小这些资源浪费怎么办题外话这大概也是Amazon涉足云存储和云计算的初始缘由吧 同时也要看到性能因素也是一个网站系统发展的最大推动力再细致的思考也难以兼容那么多未知的场景不妨多在扩展性和兼容性上下下功夫避免网站冷清痛苦网站大热更痛苦。
