这是读Thinking-Clearly paper的心得笔记,有点零碎,乱,见谅。可twitter@xds2000与我交流
规避试错的“苯”方法,学习使用可让人信服的科学方法是本Paper的主旨。
respone time,throughput它们是相关联的,还需要分场景分而制之
解决之道:
第一步,what is the goal state that you want to archieve?
第二步,profile
另外,阿姆达尔定律(Amdahl's law )需要考虑:
阿姆达定律表明:通过改进某模式得到的整体性能提高,受限于该改进模式所占的运行时间比例。
引入M/M/m公式,其中m就是你的CPU核数
想说明一个问题就是就的系统即使是可完美的,也会有阀值,超过它就会
降低性能,遵从阿姆达尔定律。
(15.relevance of the knee)
总结:
假如你有一个伴随随机请求访问的系统:
1,你的系统的每个资源都有阀值点
2. 你的系统的阀值必定小于“默认”的阀值(作者统计了一个系统默认阀值)
3.假如你无限制持续的访问系统任一资源势必导致触发性能阀值,随之
你就会遇到性能问题。
16.capacity planning (关键精华!)(注意:这里提的是随机访问的系统,例如数据库)
知道前述的性能阀值原理可以消除很多运量容量规划过程中的复杂度。
1.你的目标容量是在系统高峰时你能满意运行任务的性能数值而不是无限制的使用资源
2.假如你持续保证系统资源的使用小于性能阀值,那你系统的性能表现就会是线性的。不会
出现指数异常。
3.无论你怎样让系统超过性能阀值访问系统资源,必定会遇到性能问题(不管你想还是不想)
4.假如你遇到性能问题,你并不需要花时间放在数学模型上;你需要花时间在重新定义负载或
消除负载或增加容量来解决问题
这就是在性能管理过程中的容量规划。
参考:
1.[Paper]Thinking-Clearly paper
http://method-r.com/downloads/doc_details/44-thinking-clearly-about-performance
mysql,Linux,HighPerformance,ruby on Rails
订阅:
博文评论 (Atom)
没有评论:
发表评论