↑ 点选下方“ 51Testing软件开发网 ”
这首诗是关于英文网站操控性强化新体验的，操控性强化是两个繁杂的热门话题，牵涉到的东西非常多，我只是按照我的认知列举了操控性强化整个过程中需要考量的诸多因素。点到为止，包涵的内容以肤浅的介绍为主，假如你有看法能知会我那奥尔奈了。不管怎样，希望写作它的你有所斩获。
我眼里的英文网站操控性难题都反映了两个英文网站的“Availability”（英文叫作易用性，但那个译者也不足够多表意），过往我的重新认识是，那个英文网站假如全部或者部分不可用，那是功能难题，但假如积极响应慢、阻抗差，这才是操控性难题；可是后来我逐渐意识到，操控性难题囊括的范围更广，我还根本无法得出两个精确表述，但许多非业务方法论严重错误引起的英文网站难题都可能能算做操控性难题，比如说扩展性差，比如说ECC难题。
在英文网站操控性强化的起初阶段，也就是简而言之的“第二重修为”，做局部性的功能定位、分析和修改，考量的实际上是“强化”，这也是初入操控性优化难题的绝大多数人的重新认识。在难题发生以后，发现它和销售业务方法论没有太大关系，就开始试著找寻难题产生的原因并理清。
不论是英文网站无积极响应却是积极响应较慢，却是积极响应抛物线极度市场波动，比如说，能紧紧围绕CPU的采用问自己这样几个难题：
· 从CPU采用看控制系统与否拥挤？
· 假如控制系统拥挤，控制系统在做甚么，为甚么？（众所周知难题：HashMap不安全mammalian导致的进退两难）
· 假如控制系统空余，那么困局在哪里？（众所周知难题：IO无积极响应）
· 假如积极响应市场波动，与否存在周期性，周期性是甚么？（众所周知难题：相连迅速清空，任一周期性大批量延时接上一大批）
· 假如积极响应市场波动，操控性到波峰时控制系统在做甚么？
· 与否有大背景CPU采用？（即无压力下检视CPU的采用情况。众所周知难题：正执行的间歇任务挤占过多控制计算资源）
在这些难题中，情况虽然千变万化，简单地说，CPU的采用是核心，CPU采用率高，说明控制计算资源被充分利用，可能控制系统在实实在在地做事，反之，需要找寻其他困局。通过结合进程、线程的快照，来初步确定难题的范围。CPU采用率低的情况居多而且容易功能定位，只需要找寻其他的控制系统困局；CPU挤占率偏高的难题往往比较不容易功能定位，虽然也有一些办法。关于具体操控性难题的功能定位技术，这里不着过多笔墨，后续有机会详细介绍。
对于两个刚开始做操控性强化的英文网站控制系统，下面的事情不妨都做一做，会有立竿见影的效果：
· 对于采用的成熟的技术，技术社区、官方文档，往往会得出这种技术的白皮书或者强化指导，请参考。比如说 Struts2的官方操控性调优指南、Java6操控性强化白皮书。
· 平台和虚拟机调优。对于采用平台和虚拟机的项目来说，这是必须要做的，两个JVM的参数能对控制系统有显著的影响。比如说Linux下相连管理的参数，JVM关于堆大小分布的参数等等。
· 前端审查。这里的审查指的是通过Page speed、YSlow等工具，以及一些业界通用的法则和经验（比如说yahoo的若干条前端操控性强化法则）来评估现有页面的难题。
假如你需要控制系统的指导，不妨参考这张图：
从采用的工具上说，操控性难题的功能定位很大程度上是面向操作控制系统、虚拟机控制系统的难题功能定位。从难题功能定位的时机上说，又能分为：
……
更多精彩请点选左下角吧！
51Testing，每天给你一大波干货！
