问题描述
我们已经在laravel和MysqL中制作了移动AP的后端。该应用程序托管在AWS Ec2上，并使用RDS MysqL数据库。
我们正在使用jmeter对应用程序进行压力测试。当我们从jmeter发送多达1000个API请求时，它似乎工作正常。但是，当我们并行发送超过1000个（大约）请求时，jmeter开始收到内部服务器错误（500）作为对许多请求的响应。内部500错误百分比随着我们增加API数量而增加
通常，我们希望如果增加API，则应将它们排入队列，并且如果服务器资源不足，响应速度将会降低。我们还监视了服务器上的资源，但它们从未达到可用资源的50％
是否有任何我可以调整的超时设置或其他可能的设置，这样我们就不会在达到80％的资源使用率之前收到内部服务器错误
问候 赛德
解决方法
500是提供API的服务器中某种形式的故障的外部可见症状。您应该查看该服务器的错误日志，以查看故障的详细信息。
如果您使用php脚本来交付API，则您的mysql（rds）服务器可能已用尽连接。这可能是这样的。
一个由php驱动的Web服务器在高负载下运行许多php实例。每个php实例都会打开一个或多个与mysql服务器的连接。当php instances x connections per instance过多时，mysql服务器将开始拒绝其中的更多内容。
这是您需要做的：限制您的Web服务器一次允许使用的php实例数量。当您限制该数量时，传入的请求将排队（在OS的通信堆栈的TCP连接队列中）。然后，当实例可用于服务队列中的每个项目时，它将这样做。
Apache有一个MaxRequestWorkers parameter，其默认值非常大，为256。尝试将其设置得低得多，例如，设置为32，然后查看问题是否有所改变。
如果您可以减少请求工作程序的数量，那么您可能反而可以提高高负载性能。与尝试并行处理许多请求相比，序列化许多请求通常可以产生更好的吞吐量。
与MySQL服务器的活动连接数也是如此。显然，这取决于您使用的查询的性质，但是通常来说，更少的并发查询可以提高性能。因此，您不会通过添加MySQL连接来解决实际问题。
您应该意识到，由服务器锤击工具（例如jmeter）施加的负载类型并不代表实际负载。 1000次同时进行的jmeter操作无故障是非常好的结果。如果您的负载测试设置既强大又强大，您将始终能够使您的服务器系统崩溃。因此，决定何时停止是负载测试计划的重要组成部分。如果这是我的系统，我现在将停在1000。
为使您的应用程序在现场具有强大的性能，您可能应该对它进行编程，以通过等待随机的时间并重试来响应500状态。