精品网站建设费用 磐石网络,wordpress 域名绑定后 手机,孝感哪家做网站的公司好,php网站后台访问统计分析为什么80%的码农都做不了架构师#xff1f; 淘宝网每年的双11活动都是对其服务器性能的挑战。因为在这一天所有商品半价#xff0c;购物的用户量剧增。做为淘宝网的高层更多的关心在线用户数#xff0c;用户交易量#xff0c;总交易金额等#xff0c;做… 为什么80%的码农都做不了架构师 淘宝网每年的双11活动都是对其服务器性能的挑战。因为在这一天所有商品半价购物的用户量剧增。做为淘宝网的高层更多的关心在线用户数用户交易量总交易金额等做为一名技术人员我们可能更关心当天系统的吞吐量、每秒钟点击率以及系统资源的消耗情况等对这就是系统的性能。那么性能的本质是什么呢我试抓住一些点来解释。 基于用户体验的性能测试 但对于一个用户来说他可以不关心上面这些系统的性能参数大约有一部分的消费者会因为网站过于技术化或者性能问题而选择了离开。换言之如果你的网站速度太慢客户就会离去。这是所有的互联网用户都熟知的道理。这时你的第一想法不是“哎呀不知道站点的吞吐量怎样”而是“简直太慢了!我可没有时间在这里等到别处去吧”。现在想想人们离开你的站点是否因为性能问题所以在做性能测试的时候除关注吞吐量、点击率这些参数外我们更需要站在用户的角度来测试实际的性能感受。如果你经过测试声称网站可以承受更多的用户同时访问但实际的用户体验性非常差那么做你的性能测试又有什么意义呢 现在市场上有大量的书讨论如何设计良好的性能还有更多的书把重点放在如何使得站点更加直观、生动和易于炒作上。关于速度的好处也讨论过但如何真正并优化系统来提高用户体验呢那就是直接的用户体验测试了。有两点方法可以做一这点。一是可以把站点直接投入到能够进行数据采集和系统调优的生产环境中并祈祷你的网站不会太慢或崩溃。另一个种明智的选择是模拟真实的用户活动进行重复的测试和调优最后再投入到生产环境。 “明确”的性能需求 当测试人员进行性能测试工作时真正让他们感到困难的不是测试工具如何使用也不是如何对测试数据进行分析与系统调优对于一个经验丰富有性能工程师来说这真的不难。让他们感到困惑的是如何得到准确的量化的需求比如 A.网站可以支撑多少在线用户数 B.网站可以支持多少用户同时交易 C.电子邮件系统每秒种可以处理多少封邮件 D.可以支持多少人同时浏览网页 类似于这样的数据会出现客户对系统的性能需求中好吧有了这些需求我就开始性能工作了这些需求真的很明确么 我们来看下面的例子一个购买汽车的用户想知道 这辆汽车开100公里的耗油是多少升。对就是他坐在里面试驾的那辆车 如果你是一个严谨的汽车销售不会马上会说这辆车每公里的耗油是多少。而是在大脑中快速的列出的汽车驾驶环境 1、车上坐几个人 2、车上带多重的物品 3、路况如何是高速还是拥挤的市区 4、天气如何温度如何要开空调码 5、驾驶时间是白天还是晚上如果是晚上要开车灯 6、驾驶习惯是怎样的 你唯一能做的就是继续向客户确认更明确的需求很多时候其实客户也无法给出精确的需求。这个时候你就要多参考常规的情况下参考同类产品或尽量引导用户去明确具体的需求尽量与客户达到统一的共识。 “假设”的测试环境 现在是不是觉得性能测试有太多的前置条件它们或大或小的影响着测试的结果。 关于这些前置条件或者我们称之为假设assumption我把一些做法归纳为三个阶段。 一做了假设却不知道自己做了假设 比如前面提到的那个耗油的问题有人的做法是我就开100公里看看得出来是多少就是多少比如9L。然后就告诉别人这个车的100公里耗油是9L。 问题是这样的结果对你是OK因为你有切身的的体验知道遇到的状况可是测试的报告是要给别人甚至你都无法直接面对或者沟通的人参考。这就会很容易误导别人即便这不是你的本意而且你自已也确定你是真实的记录了结果。这里的问题在于你并不清楚自己所做的假设因为我们一直在做这样的假设。 二做过多的假设 “当路面平坦无任何红绿灯风速5km/h只有一名70kg的乘客时速稳定在70km/h良好驾驶习惯....的情况下耗油是7.1L/100km。” 这样可能很严谨但是对你的报告的读者而言这样的数据有多大意义因为他们没有你这么幸运有这么良好的环境。 三做必要和合理的假设 生活有时候是需要一些妥协和折衷如果这些折衷是必要的和合理的。因为跳出来看我们的测试需要提供有价值的信息所以为了这样有价值的信息做出必要和合理的假设是可以接受的。 好吧也许这不是你想要的答案但它是我目前给自己的解释和安慰。 性能测试环境需要在严格独立监控下管理尽量保持与真实生产环境的一致性能。 “精确”的测试数据 对于一个严谨的测试员我们的测试结果的描述也相当精确如用户每个用户的访问时间为2.8729秒10分钟系统处理请求8634个。我以前一直认为只要我把测试环境描述的很详细我的测试结果就是精确的。 实际上功能测试很容易得到测试结果而性能测试很难得到精确的量化结果我买了一辆汽车开车去上班去时车的各个功能非常正常回来的时候车的功能也非常正常。我们通过功能测试很容易得出这个车的功能没有问题。 那么性能测试呢再来看耗油情况我去时上耗油3.29升回来时耗油3.42升同样的一条路同样的人开同样的车那么是不一样的耗油结果如果我再试一遍可能情况还会有变化。所以我们很难得到精确的数据但是这丝毫不影响我们测试结果的参考价值。 “宏观/围观”的性能测试 这也是一个有趣的对立。在做性能测试特别是整个产品的性能测试的时候我们看到的是产品的核心功能和主要的大的功能模块比如数据库、web服务器、核心的daemon等等。在脑海里我们有一个架构图哪怕你没有把它画出来。所以有时候我们会想性能测试对于产品的视角是宏观的看大的组件而不是具体的细节的东西。果真是如此吗看看下面的例子 1.把daemon的log级别改为debuglog_level从2改到5之后性能下降了差不多一半。 2.关掉一个cache选项 3.打开keepalive选项 4.打开DNS反向查询 ..... 上面都是些细枝末节的设置一个配置项而已藏在DB的某张表或者某个ini里面。但是改变之后得到的性能结果可能大不相同。这些都是否改变了我们以往的看法。 Scott Barber性能测试方面的专家在他的一篇文章里讨论了这个话题。 “Macro-and Micro-testsmacro strategies and micro-plansmacro-level application usage and micro-level usage implementation detailsmacro-level result summaries for executives and micro-level test results for developers...it sounds like a day in the life of a performance tester to me.” 摘自他为Software Test Performance杂志写的一个系列文章叫做Peak Performance其中的2006年9月的一期文章名是Macro to Micro And Back Again Macro to Micro And Back Again嗯很好的诠释。 亚里士多德说世上的道理不是被讲一遍两遍而是成千上万遍是的因为Weinberg也讲了一遍就在上面提到的那本书里面。请原谅我再次引用他的话粉丝嘛。“Although its necessary to have an overview of the problemthe big picture often turns on one critical detail.” critical detail对就是这个term。其实不光是这里说的测试工作和生活中的很多事情都是一样不是要不要关心细节而是它是否critical。 那么怎么区分一个细节是不是critical或者怎样找到critical的detail呢 嗯...这是个好问题不过不好意思这个不是这里要讨论的范畴。 所以你还认为性能测试只是学习如何使用性能工具么它需要一个长期的个技术的积累我们的路还很长。也许我讲的不够本质但性能测试这个领域看到太多的新手在整天问工具的使用学会了工具的使用就大言“我会精通性能测试”。太多的公司叫新手的做性能测试环境神马的也不提供你找个工具对软件加压一下吧哎~这未免是太贬低“软件性能测试”了。 本文选自http://www.spasvo.com/news/html/20141217174341.html 转载于:https://my.oschina.net/spasvo/blog/357938
