容量规划沙龙4原则以及个人理解
个人觉得今天容量规划沙龙最核心内容即4原则1)经过良好调优的系统才容量规划
2)可扩展性好的系统才做容量规划
3)人人有容量规划意识。执行T-shirt sizing是一个巨大进步
4) 最关键的事情是测量
其他的还有
5) 用真实的产品数据做容量规划
6) 特别区分对待的容量规划场景
7) 追求响应时间与成本间平衡
欢迎其他朋友补充。
以上的点说得都很实在。
根据自己的实践做一个发散说明
1)容量规划有一个难点：在系统扩容和调优之间取得平衡。
就是停止调优的标准是什么？
目前我是根据经验值判断特定的硬件、配置参数支撑一定的访问模式、数据量、并发数、吞吐率且满足响应时间等SLA指标。 另外，检查系统不存在core dump或者大量连接超时，日志无异常等。
有较大的主观性。
2) 系统扩展性良好。
根据了解，SAP 没有结合性能测试做系统的可扩展性判断。呵呵，也许SAP架构很多年稳定了，没有必要做这个事情。
我们实践中，会设置多个场景执行性能测试或者了解系统架构判断。
如是否采用多线程技术？集群是否采用session技术？
建模采用的数学模型一般有很多的假设，就是公式成立有很多前提条件。性能测试需要判断结果是否违背了假设。同样预测时，也需要判断是否背离假设
3) 人人容量规划意识
从阿里巴巴的角度看，应该是从架构设计权衡系统扩展性、开发加入代码性能探针、性能测试判断是否该停止调优、运维部门长期跟踪反馈性能监控数据以及采购规划、数据仓库平台采集PV、运营部门预测下一年业务增长速度等多个环节。
据目前看，要走的路还很长。
对阿里巴巴而言，在网站购买的大量便宜的PC server背景下，容量规划的收益与成本不是足够一目了然，以及资源紧缺是最头大的问题。
与前同事聊天，目前广东电信研究院的容量规划的驱动力不足是当下最头痛的事情。
4) 第四个观点：测量是最关键的。
这个论点放到阿里巴巴。我个人有不同的看法。
测量是很重要。个人认为借助测量到的数据，如何构造一个合理的容量模型、如何校准模型符合实际情况更关键，否则预测的结果偏差过大导致没有太多的参考价值。
另外，目前的商业工具或者开源工具都存一些不足，如何对工具做二次开发完善，也是一件很有挑战性的工作。
回复 1# 的帖子
虽然基本不怎么看的懂，但还是支持一下！:) 容量规划前对网络，数据库等资源不一定要专业的先进行调优，但是网络，数据库等基本的错误不能犯。 构造一个合理的容量模型是很关键,但我个人觉的测量也需要一个模型,而且也很重要.如果测量的模型和实际比较吻合,那我们测量的结果的偏差性就小很多.对容量模型的参考意义就更大.当然了,合适的测量模型的建立是需要实际工作中一步一步去验证和完善的,并非一朝一夕所能达到的. 测量可以从几个方面入手：操作系统级别的。IO，内存,网络，cpu。它的颗粒需要很细致，包括cpu visit 次数，队列长度等
应用服务层：apache ,jboss,mod_jk,jdbc等。
用户体验到的响应时间
等等。teamquest在前2个做的很不错。但用户体验的响应时间不足 你们还做了这个沙龙？挺好。
容量规划的，或者其他的测试，我都觉得先从用户的角度来考虑比较好，然后才从技术角度去细比，如所说的：ＩＯ，内存，ＣＰＵ，队列等。
模型工具，需要的前提条件太多。而我们做容量规划的时候，很多时候这些东西都没有。如果是在自己公司里做产品还相对好一些，如果是做外包类型的项目，很多的因素会导致我们没有办法做这样的模型。 实际上容量规划更适合比较稳定的，有历史数据积累的产品线。
容量规划，从成本效益最高的环节入手：）
容量规划
容量规划是什么呀 学习了 那么好的总结和个性化看法怎么没人顶帮顶 容量规划前提是监控报警机制的建立和运营，有了这个机制，我们才能收集相应的历史数据并加以分析。才能根据新的目标而决定系统能承受的条件。因而容量规划是一个过程，可以不断改进的过程。
页:
[1]
