压测与性能测试，性能测试压测工具
chanong
|对于工作中用不到的性能测试我就不多说了，但是文中都提到了。今天我们就来说说在准备对系统进行压测时，如何确定压测目标TPS。首先，这个问题不仅是工作中会遇到的一个非常实际的问题，也是面试中常见的问题。这次我就写一下在面试中应该如何回答这样的问题，应该如何回答，什么样的思考会有帮助。首先，比较理想的情况是公司的系统上线时间较长且比较稳定，或者之前已经推出过类似的产品或项目。之前我在测试环境做过压力测试，只要TPS达到一定值，生产上基本没有问题。例如，一家从事保险业务的公司会定期或在特定假期推出多种新产品。每个产品都不同，但我们有丰富的过往经验，所以我们对高峰生产有很好的想法。从以往的经验来看，只要测试环境能承受主力1200 TPS，生产保险就可以了。此外，生产环境的机器数量是测试环境的四倍。因此，企业和领导直接将TPS1200列为测试环境压力测试的优化目标。确定之后，下一步就是设置不同的压力测试场景来对服务器进行压力测试，比如单一接口、混合场景、长期稳定性测试等。在进行压力测试之前，首先监控服务器硬件资源，如CPU、磁盘、网络、IO、数据库服务器以及各个数据传输系统（包括线程状态、中间件等）。然后施加压力并找到表现的拐点。如果没有，请根据您的监控一一分析瓶颈。在许多情况下，开发团队需要进行优化以达到1200 TPS 的目标。虽然上述情况是理想情况，但对于许多公司来说情况并非如此。例如，一些公司推出了运行了一年半的旧系统，但从未进行过任何性能测试。领导者希望对他们的系统进行压力测试，看看他们最多可以支持多少并发。比如是否需要购买服务器并添加配置。此时，您需要分析需要做什么才能使系统达到最大TPS。首先，在一些比较成熟或者规模较大的企业中，一般都会有各种业务监控系统，定期监控各个业务模块核心接口的调用次数、平均消耗时间等。监控通常每分钟进行一次。目前，您可以通过查看过去一周或过去一个月系统调用次数最多的日子，以分钟级的精度找到系统调用的峰值次数。例如，晚上8:10 的最大呼叫数为12,000，因此最大TPS 可以计算为12,000 除以60 等于200。接下来有的朋友可能会说，我们公司不大，没有这样的监控系统，那怎么办呢？如果你没有监控系统，你将需要打印日志，但如果你没有这个，我诚实地建议尽快换工作，不要停留太久。如果有日志，可以查看中间件的访问日志，比如nginx的access.log，里面详细记录了每个http请求的访问时间、URL、响应时间以及状态码。有了这些数据，就可以很容易地处理和编写一个脚本来统计访问次数最多的出接口和调用次数，并类似地计算和确定TPS。最重要的是。什么，你不会写剧本吗？让你的运维�**甯愠苑梗锤鼋疟荆蝗菀住�
当然，还有另一种更常见的情况。那么，由于这是一个新项目，我们没有生产数据，那么我们如何确定TPS呢？这时候，还有一个方法可以派上用场，那就是80-20规则。我们都听说过，世界上80%的财富掌握在20%的人手中。互联网也是如此，80% 的用户每天只有20% 的时间访问互联网。如果系统性能可以支持20%的时间并发，那么其他任何时间也可以支持并发。接下来我们详细讨论一下评估和计算方法。例如，假设您的系统开始抽奖，并且您想要评估它在高峰时段可以维持多少TPS。该网站拥有超过1000万注册用户和100万日活跃用户。然后您可以根据这100 万用户的每日访问量进行估算。首先要考虑的是，这100万人并不是全部都会参加抽奖，但是由于我们需要保证最大tps，所以我们可以取极值，用100万人来计算。其次，由于中午12点到早上6点之间的访问量一般很少，所以可以去掉这6个小时，算成18个小时。因此，根据80/20 规则，80% 的用户在20% 的时间访问它。用户数量为100 万x 80%，即800,000 个请求。时间为18 小时x 20% x 3600 秒，即12960 秒。 TPS=800,000 除以12960 秒约为60。这种方法虽然不如上面查看业务监控或者中间件日志的方法准确，但是比面试时闲聊要好很多，这也是一种分析思路。只要面试有理有据，实践中往往没有标准答案。也许有的朋友又说了，“这个不用担心，我们的系统没有监控，没有日志，我们也不知道日常活动是什么，我们能做什么呢？”Ta。这种情况下，你可以直接进行压测，不用担心指标，把压测结果报告写清楚发给相关方，开会讨论，最后确定你想要达到的TPS数量确保生存能力。最后，当涉及到测试和学**软件、选择优惠等时，您可以在后台通过私信进行交流。如果您需要学**材料或需要修改简历的帮助，您也可以给我们发送私人信息。您也可以在百度搜索“Testin软件测试腾讯课堂”，关注公众号“Testin软件测试”。该帐户包含许多令人兴奋的免费视频和有用的知识。