阿里云rps（阿里云rpa开发文档）

本篇文章给大家谈谈阿里云rps，以及阿里云rpa开发文档对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

微信号：cloud7591
如需了解更多，欢迎添加客服微信咨询。
复制微信号

本文目录一览：

• 1、如何解决Nginx服务自动关闭问题
• 2、阿里云服务器ECS如何选择？性能测试PTS助你测试和选择阿里云服务器

如何解决Nginx服务自动关闭问题

首先排除是否为网络问题：检查了iptable等。同时思考，如果真的是网络问题，不应该运行一段时间后，才出现无法接受新连接的现象。

为了验证，当出现问题时，我又重新启动Nginx，发现又可以接收新的请求了。也就是说出现问题时，只需要重启Nginx就可以解决，那么自然不是网络因素。

判定是否是Nginx本身的问题（不一定是指代码包括我写的配置文件）：因为这个代理服务器是为了测试fastsocket项目的稳定性，所以 Nginx是加载了fastsocket优化服务的。这时，就需要最纯粹的Nginx环境。我去掉了fastsocket服务，然后再用同样的配置启动 Nginx。这时，就排除了Nginx本身的问题。那么，究竟是否是fastsocket的bug呢？

这里先做一个小广告： fastsocket是新浪主导的一个开源项目，其通过封装socket套接字调用，无需改动服务程序，即可大幅提升服务程序性能。作者也是其中的维护者之一。这里小小推广一下：。当使用fastsocket默认加载参数时，nginx运行一段时间就无法接受新连接请求了。

定位fastsocket问题：fastsocket的大部分优化功能都是有功能开关的，默认会使用一些功能，同时可以在加载动态模块时，使用参数指定是否打开开关。这时，先做实验，从所有功能关闭开始，逐渐打开功能开关，最后定位到enable_listen_spawn功能打开时，就会出现问题。并多次做实验，确定这是一个必现的问题。

当确定可以重现后，想这难道是一个fastsocket的bug吗？于是，先跟林晓峰同学说了一声，告诉他我的发现，毕竟fastsocket是他在sina时的工作，他最为熟悉代码。他说这可能是Nginx的配置使用了accept_mutex。我的配置文件虽然没有配置accept_mutex，但是没想到Nginx的accept_mutex是默认打开的。但是他忘了为什么会这样了？依稀记得是Nginx hang在了mutex中，具体原因记不清了。所以fastsocket的说明也是要求disable accept_mutex。

因为我一直以来有这还不错的求知欲，所以一定要搞清楚这个问题。同时我认为，如果真的是一启用accept_mutex，fastsocket和nginx就会有兼容问题，那也应该算是fastsocket的bug，应该将其解决掉。

定位Nginx hang在什么位置：这个很简单，使用strace -p跟踪Nginx的每个worer进程。发现大部分worker进程是在不断的epoll_wait，而其中一个worker进程，始终停留在epoll_wait中。重试多次，每次都是停留在epoll_wait中。

现在已经确定了本次问题，当使用fastsocket的enable_listen_spawn功能时，也就是fastsocket自动为当前CPU创建本地的listen socket套接字时，就会出现问题。

解决问题

当定位到问题时，就需要一步一步的找到原因，查看为什么一个worker进程始终停留在epoll_wait中。这时候，其实思考还是要优于动手。先思考，再动手，动手之后，看到结果，再做进一步思考。

查看该worker进程停留在epoll_wait的什么位置：只能通过日志形式来判断hang在epoll_wait的哪个位置？这时，不能用内核普通的printk来打印日志，不然就会淹没于大量正常工作worker进程打印的日志中。我们需要根据pid来打印日志。

再做一个小广告：我做了一个内核小工具git@github.com:gfreewind/unit_perf.git。是用来定位内核代码的性能瓶颈工具，和一些辅助工具。大家觉得还可以的话，就给赞个星星。

它提供一个宏UP_PID_INFO_LOG用于打印指定PID的日志，pid可以通过proc来指定。

这样我在epoll_wait中增加了大量的日志。在Nginx启动后，通过proc指定就打印某个worker进程的日志。

最后发现epoll_wait是因为指定了无限等待时间，所以该worker进程一直在hang住。

Nginx让一个worker进程无限等待，这稍微颠覆了我对Nginx的认识。我认为Nginx一直都是使用无阻塞的系统调用，至少核心模块是这样处理的。那么为什么会出现这个现象呢？这时候，就需要思考，而不是动手了。

毫无疑问，accept_mutex是一个关键。它本身是用于均衡不同worker进程的负载。稍微阅读一点Nginx相关的 代码，就可以明白。在Nginx无法接收新连接请求时，一定是该轮到hang住的进程接收新连接请求。所以尽管其它进程没有hang住，但是它们是无法接 受新请求，而能够接收新请求的进程却hang住，这样就导致了问题的产生。

为什么hang住的进程无法接收到新的请求呢？这时还是思考优先。首先要勾画标准的内核TCP连接的过程，然后对比启用fastsocket 后，TCP连接的过程。很可能是这两者之间的区别，造成了问题。尤其是启用了spawn socket时，与标准流程的不同。spawn socket时，实际上为每个cpu都创建了一个本地listen 套接字的hash表，与全局的listen表区分开。这样一方面访问全局hash表时需要的锁，另一方面也做到了将TCP会话做到本地，可以尽量命中 cache。 对于同一个CPU，由于有两个listen表的存在，所以在收到新的TCP连接请求时，必须先检查本地的listen表，然后再检查全局表。 根据这样的流程和现象，应该是所有的连接请求，都被发到其它的CPU，并且匹配中了其它CPU的本地listen表，所以全局表中的listen socket套接字一直没有被匹配到。

那么hang住的进程，既没有连接请求匹配本地listen表中的套接字，而全局表也一样，因为被请求都被其它CPU命中了本地的套接字。

所以问题更为明朗了，hang住的进程所在的CPU不能收到任何新连接请求。

这时其实已经到了冲刺的时候了。开始的时候，我还想着，是否是fastsocket影响了数据包的分发，还想检查一下代码。但一想，还是先看看 RPS的设置吧——虽然我没有设置网卡的任何RPS。结果出乎我意料，原来阿里云ECS服务器默认就把网卡的RPS设置了，唯一的外网网卡的RPS设置为 了0000，所以只有CPU 0能收到新连接请求，而另外的CPU1收不到任何的连接请求，这就造成了运行在CPU1上的worker进程hang住。

最后我修改了该网卡的RPS设置，使其可以将数据包分发到不同的CPU上。这样在加载了fastsocket后，即使打开了accept_mutex，Nginx也可以正常工作了。

本次过程，虽然最后发现只是服务器配置的问题，但整个儿过程还是收获不少。唯一的遗憾，是还没有定位Nginx对与epoll_wait的超时计算。开始的时候，都是500ms，后面因为什么因素变成了无限。这留到有时间的时候，再阅读Nginx源码吧。

阿里云服务器ECS如何选择？性能测试PTS助你测试和选择阿里云服务器

阿里云服务器ECS如何选择？很多新手用户并不知道PTS是什么，如果你不知道如何选择阿里云服务器ECS产品，性能测试PTS可以很好的帮助你快速对云服务器进行压力测试，从而助你选择适合自己的阿里云服务器ECS，下面是性能测试PTS详解！

阿里云开发者社区最近推出了一个“ ECS 选款利器！PTS助您快速上云 ”活动，PTS性能压测包仅需0.99/月起，真实模拟，免去繁琐的搭建和维护成本！现在您可以只支付10块钱不到的试用成本，即可体验使用 PTS 来帮助 ECS 进行容量规划选择合适规格的整个流程！

完成动手实验的同学，即可参与抽奖活动，小米手环 6、蓝牙键盘、掌上游戏机、笔记本支架、 数据线、优惠券等丰富奖品等您来拿！限量 1500 份，抽奖即得，百分百中奖哦！

性能测试PTS（Performance Testing Service）是具备强大的分布式压测能力的SaaS压测平台，可模拟海量用户的真实业务场景，全方位验证业务站点的性能、容量和稳定性。

PTS旨在简化性能压测本身的工作。

PTS目标是将性能压测本身的工作持续简化，使您可以将更多的精力回归到关注业务和性能问题本身。在PTS平台上，您可以用较低的人力和资源成本，构造出最接近真实业务场景的复杂交互式流量，快速衡量系统的业务性能状况，为性能问题定位、容量配比、全链路压测的流量构造提供最好的帮助。进而提升用户体验，促进业务发展，最大程度实现企业的商业价值。

业务场景

PTS广泛应用于各种压力测试和性能测试场景，包括但不限于以下场景：

PTS孵化于服务阿里巴巴全生态五年以上的单链路、全链路压测平台，是阿里巴巴内部最佳实践的输出。该平台对内除了支持日常的外部流量压测之外，同时支持了大大小小的促销活动，如天猫双11、双12和年货节等。

压测流程

PTS提供全面高效的压测流程：

压测流程说明：

1.在PTS控制台上，准备压测API数据，构造压测场景，定义压测模式、量级等；支持随时启停压测，压测过程中可调速。

2.压测启动后，PTS后台的压测控制中心将自动调度压测数据、压测任务和压测引擎。

3.通过随机调度全国上百个城市和运营商的内容分发网络CDN （Content Delivery Network）节点，发起压测流量。保证从虚拟用户并发量、压测流量的分散度等维度都接近真正的用户行为，压测结果更加全面和真实可信。

4.通过压测引擎向您指定的业务站点发起压测。

5.压测过程中，通过集成云监控、ARMS（应用实时监控服务）产品，结合PTS自有的监控指标，实时采集压测数据。

6.在PTS控制台，实时展现压测数据，进行过程监控；压测结束后，生成压测报告。基于整个压测场景的性能表现，定位性能问题、发现系统瓶颈。

压测创建方式

PTS支持以下4种方式创建压测场景（或称压测用例），如下图所示：

说明：

方式一：PTS自研零编码可视化编排，使用自研强大引擎压测。

方式二： 使用PTS自研云端录制器，零侵入录制业务请求并导入1中的自研交互中进行进一步设置。

方式三： 将导入脚本压测 1中的PTS自研交互中，使用PTS自研引擎。

方式四：JMeter压测并使用原生JMeter引擎进行压测，PTS提供自定义的压力构造和监控数据汇聚等产品服务。

其中，方式一、二、三由于使用了PTS的自研引擎，具备RPS（Requests per Second）吞吐量压测模式、秒级启动、实时控制、定时压测和流量遍布全国运营商网络的差异化能力。

方式一是PTS最核心的一种压测场景创建方式，所有资源包均可使用。其他几种创建方式面向不同规格资源包开放。

适用于多业务场景

不论您处于哪个行业，在以下业务场景（但不限于），PTS都是您值得信赖的性能测试工具。

适用行业广泛

PTS应用行业广泛，涉及电商、多媒体、金融保险、物流快递、广告营销、社交等等。

PTS服务阿里巴巴全生态多年，支持了天猫双11、双12、年货节等大促活动。植根于电商行业的PTS，对电商的典型业务模型支持得更友好，压测来源更广泛，脉冲能力和流量掌控能力更强。

PTS自商业版发布以来，吸引了来自多媒体、金融保险、政务等众多行业的用户，以其强大的压测场景编排能力和报表能力，帮助用户快速发现问题，进行针对性地调优，提升了系统承压能力。

适用于多种网络环境

不论您的业务位于公有云、专有云、混合云或者自建IDC中，只要能够通过公网访问，PTS都能够通过遍布全国上百个城市和各运营商的CDN节点发起压测流量，最大程度地模拟真实业务场景。

适用于使用HTTP/HTTPS/WebSocket等协议的客户端

PTS本身的GUI模式支持HTTP/HTTPS协议的压测，无论您的客户端是自研的App、移动端网页、PC端网页、微信小程序还是C/S结构的软件，都可以使用PTS进行压测。PTS同时集成了开源JMeter，支持更多的协议和场景，例如您可以通过“JMeter + WebSocket插件”的方式，对使用WebSocket协议的客户端进行压测（在PTS上传相应的插件JAR文件即可），其他协议以此类推。

下面以电商典型业务场景为例，为您介绍如何在PTS中编排压测场景。

什么是压测场景

要发起一次性能压测，首先需要创建一个压测场景。压测场景中包含一个或多个并行的业务，每个业务包含一个或多个串行的请求。

示例

淘宝网需要对产品A和B相关的页面（即存在多个API）进行压测，假设其主要业务场景为：

业务A：浏览产品A。

业务B：购买产品B（登录 → 浏览产品B → 加入购物车 → 提交订单）。

那么在压测场景中的设置如下。

串联链路1：浏览产品A 和串联链路2：购买产品B是并行关系。

根据业务逻辑，一部分用户在浏览产品A，另一部分用户在进行购买产品B的一系列操作，即两个业务是同时发生的，所以将它们设置为两个串联链路，压测中会并行发起请求。

串联链路中的多个API是串行关系。

根据业务逻辑，串联链路2：购买产品B中的一系列用户行为是存在先后顺序的，所以将这些存在先后关系的API添加到一个串联链路中，PTS压测中会按照顺序发起压测。

综合来看，在压测中，示例中的浏览产品A的API和登录的API，会同时发起压测流量。更多性能测试PTS场景示例，可参考阿里云帮助资料： 性能测试 PTS最佳实践

关于阿里云rps和阿里云rpa开发文档的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。