“重度”并发用户 Nginx - Laravel - Google 计算引擎答案

【问题标题】："Heavy" simultaneous users Nginx - Laravel - Google compute engine“重度”并发用户 Nginx - Laravel - Google 计算引擎
【发布时间】：2018-01-11 00:50:28
【问题描述】：

我正在使用 Laravel（中等静态网络）在 nginx 中运行服务器，例如，我在 1 分钟内同时使用 500 constant load 的用户（在那一分钟内不是分布式用户）。

得到这个错误：

unix:/var/run/php/php7.1-fpm.sock 失败 - 资源暂时不可用

cginx.conf

worker_processes auto;

events {
    use epoll;
    worker_connections 1524; #in my case it should be 1024, but well..
    multi_accept on;
}
http {
    #with this I reduce disk usage a lot
    client_body_buffer_size 10K;
    client_header_buffer_size 1k;
    large_client_header_buffers 2 1k;
    reset_timedout_connection on;

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

www.conf

pm.max_children = 500
pm.start_servers = 20
pm.min_spare_servers = 20
pm.max_spare_servers = 64

Google 计算引擎的结果：

f1-micro (1 vCPU, 0,6 GB) - Is supporting 40 - 60 requests per second
g1-small (1 vCPU, 1,7 GB) - Is maintaining 80 request per second
n1-standard (1vCPU, 3,75 GB) - - Is maintaining 130 request per second
n1-standard-2 (2vCPU, 7,5 GB) - Is maintaining 250 request per second
.
.
n1-standard-16 (16 vCPU, 60 GB) - Is maintaining 840 request per second

最后一个是第一个通过测试，其余的将 Bad Gateways 错误从 200 个用户减少到 400 个

如果我用微型实例测试不是 30 秒内分布的 2000 个用户，那么很好，但不能同时发送请求。

从 2 核开始，CPU 级别显示非常好，与磁盘操作等相同。

所以经过大量测试后，我有一些问题：

1) 这正常吗？对我来说不是，需要16个核心来运行一个简单的网络是不正常的..还是压力测试太重而正常？

2) 那么，我错过了什么吗？谷歌是否以某种方式限制每秒请求？

3) 给定配置文件的正常参数是什么？

欢迎任何其他帮助

【问题讨论】：

laravel 压力测试不好。
@LawrenceCherone 但我认为错误来自 nginx 或 gcloud ..
GCE 小型/微型实例没有完整的 CPU 内核，并且 CPU 时间是通过一个系统分配的，该系统归结为“您每秒获得 X 个 cpu 份额，具有一定的突发性”，一旦您突破你的爆发限额，你将受到严重、痛苦的限制，事情将以新的和创新的方式失败。我强烈建议不要将它们用于几乎不完全空闲的 CPU。
是的，我不确定投诉是什么——如果您支付最便宜的计划，比名为“标准”的计划便宜几倍，您是否真的希望仍能收到与“标准”中的性能相同吗？这些测试似乎唯一可以确认的是，您的“中等静态站点”实际上在手头的计算资源方面效率很低。
@TrOnNe，如果任何答案有帮助，请考虑奖励赏金。截至 20 小时前，该问题已不再出现；除非您在接下来的几个小时内接受答案或奖励赏金，否则一半的赏金将失效。

标签： php laravel nginx google-compute-engine

【解决方案1】：

TBH，目前尚不完全清楚您要通过此测试实现什么目标，尤其是在将 GCE 纳入方程式时。

如果您的“中型静态网站”网站为每个页面执行十几个 SQL 查询，每个可能有几个 JOINs，以及各种其他资源密集型操作，那么您就不足为奇了距离实现C10K 还很遥远。

您在各种 GCE 实例中的测试结果看起来相当一致，这证明应该归咎于您的代码。如果您想排除 GCE 是性能问题的原因，那么下一个合乎逻辑的步骤似乎是测试它之外的性能。

您似乎最关心在更便宜的实例上收到Bad Gateway 错误，所以，让我们弄清楚为什么会发生这种情况。

您的后端只能在给定的时间内处理一定数量的请求，在最便宜的计划中大约每秒几十个。
它的配置没有明确说明资源耗尽后应该发生什么。使用手头的配置，您只能在最便宜的实例上每秒推送 40 个请求，但是，配置设置为让 Laravel 同时处理 500 个请求，在 1 个 vCPU w/0.6GB 总 RAM 上，每个请求大约 1MB RAM，对于由动态框架提供支持的“中等静态网络”而言，其规模较小，会导致阻抗不匹配。
因此，您遇到错误也就不足为奇了，这显然是由于背压建立时阻抗不匹配，而后端尝试处理永无止境的请求时可能会耗尽 RAM。

那么，解决方案是什么？

解决的办法是清楚了解后端生成每个页面需要多少资源，随后限制从反向代理到后端的同时连接数永远不超过这样的一定连接数，与http://nginx.org/r/limit_req 和/或http://nginx.org/r/limit_conn，视情况而定。通过这种方式，您可以捕获和监控过载情况，并向用户提供适当的错误消息，和/或编写基础架构自动动态调整大小的脚本。

除了上述内容之外，另一个好主意是缓存后端的结果，前提是它实际上是生成的“静态”内容，没有针对每个用户的自定义，这可以让您考虑当指向您网站的链接发布在 Slashdot/Reddit/Twitter 上，导致单个“静态”页面的流量激增，然后可以在整个活动期间缓存该页面。否则，如果内容实际上不是“静态的”，那么由您决定走哪条路以及采取哪种折衷方案——我建议看看每个请求的定制是否真的有必要，以及未定制的版本是否可能是合适的，尤其是对于类似 Slashdot 的场景。

【讨论】：

另外，nginx 中的缓存也会有所帮助。
@sfratini，确切地说-在上面原始答案的最后一段中已经提到了 nginx 中的缓存。 :-)

【解决方案2】：

在具有 2vcpu 和 7gb 内存的机器上，我每秒可以处理更多 1000 个请求你没有提到你需要每个请求的 ram，我也建议将 php socket 更改为 tcp 连接，它允许我处理 10x 请求

【讨论】：