性能需求和监控(冲突时的文件备份2013-08-0609-44-17)学案.ppt

性能监控-中间件 ?中间件 ?tomcat，weblogic，jboss，Apache 我们把Tomcat的调整可以分为两类来详细描述： 调整非Tomcat组件，例如Tomcat运行的操作系统和运行Tomcat的java虚拟 自身调整 修改Tomcat自身的参数，调整Tomcat配置文件中的参数。 性能测试需求和监控分析 性能测试需求分析的重要意义 性能测试需求分析的正确性是整个性能测试工作的最基本前提 性能测试点的选取原则 发生频率非常高的（例如：139邮箱核心业务系统中的登录、收发邮件等业务，它们在每天的业务总量中占到90%以上） 关键程度非常高的（产品经理认为绝对不能出现问题的，如登录等） 资源占用非常严重的（导致磁盘I/O非常大的，例如某个业务进行结果提交时需要向数十个表存取数据，或者一个查询提交请求时会检索出大量的数据记录） 性能测试需求描述要求 准确 如**系统必须在不超过 10 秒的响应时间内,处理 20 起登录任务。再如发邮件时间最大不超过5秒以及平均时间在2秒以内。 一致 用户和性能测试工程师对有关术语的理解要一致,如:并发用户数、在线用户数、注册用户数: 特定 性能测试的需求一定是有条件的。 检查系统后台关键业务数据10G、操作数据量为20K, 1500 个用户、500 个并发用户运行的负载下，连续运行12小时过程中,业务操作是否满足性能需求。 获取性能测试需求的方法 开发相关文档 相似项目性能需求 业界公认标准 用户使用模型 二八原则 服务访问日志 工作中的性能测试需求 我们得到的测试需求往往是这么描述的： 这个系统能否支撑200万的vu（每天登录系统的人次）。 言下之意是：按照目前的硬件性能和数量，系统能否支 撑200万的vu。 然而，我们了解的是吞吐量、响应时间等指标 ?吞吐量：系统每秒能处理的请求数，这个指标从服务器 的视角，表征系统容量 ?响应时间：从请求发出到第一个字节返回所需要的时间， 这个指标从用户的视角，表征系统响应速度。 常见的性能需求如下 WEB首页打开速度5s以下，web登陆速度 15s以下。 邮件服务支持50万个在线用户 计费话单成功率达到99.999%以上。 在100个并发用户的高峰期，邮箱的基本功能，处理能力至少达到10TPS 系统能在高于实际系统运行压力1倍的情况下，稳定的运行12小时 这个系统能否支撑100万的vu（每天登录系统的人次） 工作中的性能测试需求 ?怎么办：只能由我们根据经验，把200万vu转 化成一系列的指标。 ?响应时间：根据国外的一些资料，一般操作的响 应时间为2，5，8秒，2秒内优秀，5秒内良好，8秒内可接受， 其它一些特殊的操作，如上传，下载可以依据用户体验的情况 ，延长响应时间。 ?吞吐量：可以根据已经上线的类似产品进行估计。 或者，采用80/20原则进行估计。我们经常使用 的是80/20原则。 工作中的性能测试需求 ?怎么办：只能由我们根据经验，把200万vu转 化成一系列的指标。 ?响应时间：根据国外的一些资料，一般操作的响 应时间为2，5，8秒，2秒内优秀，5秒内良好，8秒内可接受， 其它一些特殊的操作，如上传，下载可以依据用户体验的情况 ，延长响应时间。 ?吞吐量：可以根据已经上线的类似产品进行估计。 或者，采用80/20原则进行估计。我们经常使用 的是80/20原则。 工作中的性能测试需求 ? 80/20原则，又称帕累托效应，比如，80%的社会财富掌握在20%的人手里。 ?应用于测试：从vu计算吞吐量 ?根据80/20原则，80%的用户会在20%的繁忙时间内登陆。则繁忙时间每秒大概会有 （2000000*80%）/(24*3600*20%)=100个用户登陆 ，也就是说，登陆操作的吞吐量是100TPS 工作中的性能测试需求 ?虽然已经有了响应时间和吞吐量指标，但是 测试需求还是不明确的。 ?我们的测试目的是什么？ ?是验证当前硬件和软件配置能否支撑200万vu？ ?是测试当前的硬件和软件配置最多能支撑多少vu? ?是帮助开发寻找性能瓶颈？ 工作中的性能测试需求 ?根据我们的经验，开发的需求往往是这样的，^_^： ?首先，请你们验证能否支撑200万vu。 ?如果不能支撑，请找一下性能瓶颈。 ?主要性能瓶颈解决后，请估计能支撑多少vu，如 果不到200w，请估计要加多少机器。 ?如果能支撑200万，请再加压，看看达到300万 vu的时候，系统的性能。 ?这么一细化，需求基本明确了。 性能测试案例分析 SMTP发邮件峰值TPS 按照139邮箱20000万注册用户，其中日活跃用户数为1.5%的规模计算： 日活跃用户=20000*1.5%=300万 日活跃用户人均每天发6封邮件，用户使用客户端收发邮件