这个问题是关于瑞士应用程序云的,而不是关于Amazon.的。
我的应用程序使用50个线程。总之,它们以每秒25-200次的速度向S3发出请求。在运行它们10-30秒之后,我开始得到这样的异常:
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秒之后,我又得到了这些异常。
索款率有限制吗?
发布于 2016-10-31 09:34:22
没有出站流量限制或DoS保护。
Swisscom AppCloud有一个针对S3的DoS策略(称为Dynstrg,)访问激活,在一定级别后拦截请求。此检测标准目前由每个源IP的200个TPS (事务/秒,TCP会话)触发,然后该IP被阻塞至少120秒。
瑞士银行目前正在讨论增加这些触发因素。
发布于 2016-10-30 23:45:45
如果Cloud提供者有任何类型的出站流量限制,为什么不自己发现呢?此外,您需要排除应用程序存在某种缺陷或缺陷的可能性。
因此,为了发现是否存在任何出站请求限制,和排除了应用程序出现某种问题的可能性,我们可以执行以下步骤:
好的,但是,现在的问题是:如何在技术上或实际上实现这些步骤?工作不多吗?
嗯,这是可能的,而且,不,这是,而不是,做了很多工作。我花了20分钟,想出了一组命令/脚本/docker映像来模拟这个过程。
所以,第一步你可以通过你自己来实现。也许在其他地方部署一个简单的web服务,仅此而已。步骤2更复杂,只需执行以下CLI命令即可实现:
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日志”来检查负载测试的结果:
cf logs LoadTestFromCloudFoundry此外,还有一个明显的示例这里,也包含自述文档这里。
如果应用程序中存在问题,那么针对外部应用程序执行这样的负载测试可能会给您带来强烈的洞察力,或者如果(在本例中是Swisscom AppCloud)确实阻止了一定数量的每秒请求(RPS)。
但是,现在,如果您得出的结论是云创建提供商以某种方式阻塞了,您必须联系他们的支持。一家像样的供应商不应对向其服务付款的客户施加任何形式的出站RPS限制。
这是我在这个问题上的两分钱。:-)
https://stackoverflow.com/questions/40319387
复制相似问题