首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >问答首页 >过度使用S3结束与套接字关闭?

过度使用S3结束与套接字关闭?
EN

Stack Overflow用户
提问于 2016-10-29 13:06:09
回答 2查看 477关注 0票数 1

这个问题是关于瑞士应用程序云的,而不是关于Amazon.的。

我的应用程序使用50个线程。总之,它们以每秒25-200次的速度向S3发出请求。在运行它们10-30秒之后,我开始得到这样的异常:

代码语言:javascript
运行
复制
2016-10-29 14:36:58 [APP/PROC/WEB/0] OUT com.amazonaws.AmazonClientException: Unable to execute HTTP request: Socket is closed
2016-10-29 14:36:58 [APP/PROC/WEB/0] OUT at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeHelper(AmazonHttpClient.java:956)
2016-10-29 14:36:58 [APP/PROC/WEB/0] OUT at com.amazonaws.http.AmazonHttpClient$RequestExecutor.doExecute(AmazonHttpClient.java:661)
2016-10-29 14:36:58 [APP/PROC/WEB/0] OUT at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeWithTimer(AmazonHttpClient.java:635)
2016-10-29 14:36:58 [APP/PROC/WEB/0] OUT at com.amazonaws.http.AmazonHttpClient$RequestExecutor.execute(AmazonHttpClient.java:618)
2016-10-29 14:36:58 [APP/PROC/WEB/0] OUT at com.amazonaws.http.AmazonHttpClient$RequestExecutor.access$300(AmazonHttpClient.java:586)
2016-10-29 14:36:58 [APP/PROC/WEB/0] OUT at com.amazonaws.http.AmazonHttpClient$RequestExecutionBuilderImpl.execute(AmazonHttpClient.java:573)
2016-10-29 14:36:58 [APP/PROC/WEB/0] OUT at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:445)
2016-10-29 14:36:58 [APP/PROC/WEB/0] OUT at com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:4041)
2016-10-29 14:36:58 [APP/PROC/WEB/0] OUT at com.amazonaws.services.s3.AmazonS3Client.putObject(AmazonS3Client.java:1581)
2016-10-29 14:36:58 [APP/PROC/WEB/0] OUT at <my_code_from_here>.putFile(S3Service.java:49)

在重新启动应用程序或等待几分钟之后,问题就解决了,但是当我启动并重新在S3上加载时,在10-30秒之后,我又得到了这些异常。

索款率有限制吗?

EN

回答 2

Stack Overflow用户

回答已采纳

发布于 2016-10-31 09:34:22

没有出站流量限制或DoS保护。

Swisscom AppCloud有一个针对S3的DoS策略(称为Dynstrg,)访问激活,在一定级别后拦截请求。此检测标准目前由每个源IP的200个TPS (事务/秒,TCP会话)触发,然后该IP被阻塞至少120秒。

瑞士银行目前正在讨论增加这些触发因素。

票数 1
EN

Stack Overflow用户

发布于 2016-10-30 23:45:45

如果Cloud提供者有任何类型的出站流量限制,为什么不自己发现呢?此外,您需要排除应用程序存在某种缺陷或缺陷的可能性。

因此,为了发现是否存在任何出站请求限制,排除了应用程序出现某种问题的可能性,我们可以执行以下步骤:

  1. 在外部服务器中部署任何web服务应用程序。换句话说,没有在同一个云创建域部署(即没有部署在Swisscom AppCloud中)。实际上,它不需要是一个适当的web服务,但是一个"nc -l端口“已经可以完成这项工作了--只是为了监听一个TCP端口。
  2. 然后,我们可以在Cloud (即Swisscom AppCloud)中部署一个应用程序,该应用程序每秒向我们在步骤1中部署的外部web服务应用程序发出大约300个请求。

好的,但是,现在的问题是:如何在技术上或实际上实现这些步骤?工作不多吗?

嗯,这是可能的,而且,不,这是,而不是,做了很多工作。我花了20分钟,想出了一组命令/脚本/docker映像来模拟这个过程。

所以,第一步你可以通过你自己来实现。也许在其他地方部署一个简单的web服务,仅此而已。步骤2更复杂,只需执行以下CLI命令即可实现:

代码语言:javascript
运行
复制
cf push LoadTestFromCloudFoundry --no-hostname --no-route --docker-image gsmachado/loadtest-docker --health-check-type none -c 'loadtest -t 20 -c 10 --rps 10 -k https://IP_ADDRESS_TO_YOUR_EXTERNAL_WEBSERVICE:PORT'

在这个例子中,我们推出了一个名为"LoadtestFromCloudFoundry“的应用程序,它没有任何主机名,没有任何路由,也没有任何健康检查类型。另外,我们正在指定一个码头映像(gsmachado/loadtest),它已经在DockerHub上发布了,但是您可以检查源代码这里 (给它一个星号!它是开源的!)。选项'-c‘指定要在这个docker容器中运行的命令,它实际上是运行在Cloud中的一个应用程序。这个停靠容器使用项目载荷试验来执行对特定web目标的请求。您可以检查所有文档并提出自己的'-c‘命令。在这个特殊的例子中,我们定义了在20秒内,我们希望使用10个并发客户端每秒执行20个请求。cf push命令需要一段时间才能执行,因为Cloud应该部署整个docker容器。

您可以通过检查“cf日志”来检查负载测试的结果:

代码语言:javascript
运行
复制
cf logs LoadTestFromCloudFoundry

此外,还有一个明显的示例这里,也包含自述文档这里

如果应用程序中存在问题,那么针对外部应用程序执行这样的负载测试可能会给您带来强烈的洞察力,或者如果(在本例中是Swisscom AppCloud)确实阻止了一定数量的每秒请求(RPS)。

但是,现在,如果您得出的结论是云创建提供商以某种方式阻塞了,您必须联系他们的支持。一家像样的供应商不应对向其服务付款的客户施加任何形式的出站RPS限制。

这是我在这个问题上的两分钱。:-)

票数 1
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/40319387

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档