针对今天容量规划沙龙由于时间关系没有回答的问题--阿里巴巴的容量规划设计方案,做一个简单的说明。
呵呵,我去年10月份这个问题写了很长的技术方案书。大致思路如下
容量规划方案贯穿软件开发整个流程。
针对已经上线运行的系统
1) 性能需求: 从数据仓库平台或者web 日志分析工具awstats分析access_log日志得到用户访问模型;
从监控中心(cacti 和nigos ) 获取服务器资源消耗数据,如cpu,io,内存,网络等细节,得到系统资源消耗模型。
如果要求更细致的颗粒,可以在应用层加以监控,如jmx获取JVM 的性能;oracle db 通过statspack获取性能
2) 性能测试与监控
建立性能测试场景(用户、数据量、硬件、软件系统等),执行性能测试;获取当前系统的承受负荷以及获取临界值。
经过确认,系统经过良好调优、且无伸缩性问题后。可以按照容量规划理论来看,寻求伸缩因子。其=1/(1-利用率%)。
比如找到瓶颈资源临界点,如50%资源消耗,75%资源消耗。一旦伸缩因子>2后,容量预测的估计偏差难以估计,因为已经不是线性关系
3) 建模以及预测
采用开源工具java model tool或者 pdq (2工具可以从sourceforge.net下载) ,建立客户到达时间分布与服务时间分布等众多容量规划参数,模型可以选择排队网络。流程:建模->MVA求解- 与性能测试结果对比校准模型,迭代逼近误差容忍范围。
what-if 预测可以从 增加并发数、合并/拆分应用、变更硬件等角度考虑
呵呵,当然也可以尝试找teamquest临时 license。
针对新开发系统:
1) 性能需求: 可以定义得更加苛刻一些。
参考同类系统,初步用TPCC 等参数比较。
实际上,这样可能误差较大。
另外,需要架构师评估系统是否有代码保证最大连接数限制
2) 性能测试与监控
场景细分更加细致,获取新系统承受负荷以及获取临界值。
3) 建模与预测
模型校准的工作量比较大。
需要长期与生产系统实际的用户行为、系统资源消耗、响应时间、吞吐率等SLA指标比较,修正容量规划模型。
这个过程可能很漫长。
呵呵,我去年10月份这个问题写了很长的技术方案书。大致思路如下
容量规划方案贯穿软件开发整个流程。
针对已经上线运行的系统
1) 性能需求: 从数据仓库平台或者web 日志分析工具awstats分析access_log日志得到用户访问模型;
从监控中心(cacti 和nigos ) 获取服务器资源消耗数据,如cpu,io,内存,网络等细节,得到系统资源消耗模型。
如果要求更细致的颗粒,可以在应用层加以监控,如jmx获取JVM 的性能;oracle db 通过statspack获取性能
2) 性能测试与监控
建立性能测试场景(用户、数据量、硬件、软件系统等),执行性能测试;获取当前系统的承受负荷以及获取临界值。
经过确认,系统经过良好调优、且无伸缩性问题后。可以按照容量规划理论来看,寻求伸缩因子。其=1/(1-利用率%)。
比如找到瓶颈资源临界点,如50%资源消耗,75%资源消耗。一旦伸缩因子>2后,容量预测的估计偏差难以估计,因为已经不是线性关系
3) 建模以及预测
采用开源工具java model tool或者 pdq (2工具可以从sourceforge.net下载) ,建立客户到达时间分布与服务时间分布等众多容量规划参数,模型可以选择排队网络。流程:建模->MVA求解- 与性能测试结果对比校准模型,迭代逼近误差容忍范围。
what-if 预测可以从 增加并发数、合并/拆分应用、变更硬件等角度考虑
呵呵,当然也可以尝试找teamquest临时 license。
针对新开发系统:
1) 性能需求: 可以定义得更加苛刻一些。
参考同类系统,初步用TPCC 等参数比较。
实际上,这样可能误差较大。
另外,需要架构师评估系统是否有代码保证最大连接数限制
2) 性能测试与监控
场景细分更加细致,获取新系统承受负荷以及获取临界值。
3) 建模与预测
模型校准的工作量比较大。
需要长期与生产系统实际的用户行为、系统资源消耗、响应时间、吞吐率等SLA指标比较,修正容量规划模型。
这个过程可能很漫长。