504从网站到许多cUrl的超时

Question

我有一个32 gb ram /8处理器的专用服务器。我在我的所有站点上使用cUrl php，显示一些代码。我制作cUrl的网站是一个VPS，在那里我使用了另一个带有多个代理的cUrl，该代理可以切换每个请求。

因此，我使用这样的方式:在站点A(专用服务器)卷到站点B (VPS)。cUrl代码如下所示：

$url = "https://siteB.com/code";
$ch = curl_init();
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt ($ch, CURLOPT_URL, $url);
curl_setopt ($ch, CURLOPT_CONNECTTIMEOUT, 7);
curl_setopt ($ch, CURLOPT_TIMEOUT, 7);
$curl_res = curl_exec($ch);
curl_close ($ch);

我的问题是，在一个网站(在本例中的站点A)上，我每天有大约300 000名访问者，如果站点B由于任何原因没有响应，站点A会超时504，而在专用服务器上的其他网站工作正常。

在站点A的错误日志中，我有这样的错误：

25329#25329: *3623 upstream timed out (110: Connection timed out) while reading response header from upstream

当我检查Nginx时，我看到了从40-50的写作(通常是这样)到许多写作过程，从这里开始它就超时了。

Active connections: 1756 
server accepts handled requests
11367 11367 11377 
Reading: 0 Writing: 1395 Waiting: 361

我的nginx配置是：

worker_processes auto;
worker_rlimit_nofile 65535;

events {
    multi_accept on;
    use epoll;
    worker_connections 65535;
}

http {
    ## Basic Settings ##
    client_body_buffer_size        128k;
    client_body_timeout            5s; # Use 5s for high-traffic sites
    client_header_timeout          5s; # Use 5s for high-traffic sites
    client_max_body_size           1024m;
    keepalive_timeout              30s;
    open_file_cache                max=200000 inactive=20s;
    open_file_cache_errors         on;
    open_file_cache_min_uses       2;
    open_file_cache_valid          30s;
    port_in_redirect               off;
    reset_timedout_connection      on;
    send_timeout                   5s;
    sendfile                       on;
    server_name_in_redirect        off;
    server_names_hash_bucket_size  1024;
    server_names_hash_max_size     1024;
    server_tokens                  off;
    tcp_nodelay                    on;
    tcp_nopush                     on;
    types_hash_max_size            2048;

    ## DNS Resolver ##
    # If in China, enable the OpenDNS entry that matches your network connectivity (IPv4 only or IPv4 & IPv6)
    # OpenDNS (IPv4 & IPv6)
    #resolver                      208.67.222.222 208.67.220.220 [2620:0:ccc::2] [2620:0:ccd::2];
    # OpenDNS (IPv4 only)
    #resolver                      208.67.222.222 208.67.220.220;
    # Google Public DNS (IPv4 & IPv6)
    #resolver                      8.8.8.8 8.8.4.4 [2001:4860:4860::8888] [2001:4860:4860::8844];
    # Google Public DNS (IPv4 only) [default]
    resolver                       8.8.8.8 8.8.4.4;

    ## Real IP Forwarding ##
    set_real_ip_from 127.0.0.1;

    # CloudFlare IPs
    # List from: https://www.cloudflare.com/ips-v4
    set_real_ip_from 103.21.244.0/22;
    set_real_ip_from 103.22.200.0/22;
    set_real_ip_from 103.31.4.0/22;
    set_real_ip_from 104.16.0.0/12;
    set_real_ip_from 108.162.192.0/18;
    set_real_ip_from 131.0.72.0/22;
    set_real_ip_from 141.101.64.0/18;
    set_real_ip_from 162.158.0.0/15;
    set_real_ip_from 172.64.0.0/13;
    set_real_ip_from 173.245.48.0/20;
    set_real_ip_from 188.114.96.0/20;
    set_real_ip_from 190.93.240.0/20;
    set_real_ip_from 197.234.240.0/22;
    set_real_ip_from 198.41.128.0/17;
    # List from: https://www.cloudflare.com/ips-v6
    set_real_ip_from 2400:cb00::/32;
    set_real_ip_from 2405:8100::/32;
    set_real_ip_from 2405:b500::/32;
    set_real_ip_from 2606:4700::/32;
    set_real_ip_from 2803:f800::/32;
    set_real_ip_from 2c0f:f248::/32;
    set_real_ip_from 2a06:98c0::/29;

    # Replace with correct visitor IP
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    ## MIME ##
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    ## Logging Settings ##
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    ## Gzip Settings ##
    gzip on;
    gzip_buffers 16 8k;
    gzip_comp_level 5;
    gzip_disable "msie6";
    gzip_min_length 256;
    gzip_proxied any;
    gzip_types
        application/atom+xml
        application/javascript
        application/json
        application/ld+json
        application/manifest+json
        application/rss+xml
        application/vnd.geo+json
        application/vnd.ms-fontobject
        application/x-font-ttf
        application/x-javascript
        application/x-web-app-manifest+json
        application/xhtml+xml
        application/xml
        font/opentype
        image/bmp
        image/svg+xml
        image/x-icon
        text/cache-manifest
        text/css
        text/javascript
        text/plain
        text/vcard
        text/vnd.rim.location.xloc
        text/vtt
        text/x-component
        text/x-cross-domain-policy
        text/x-js
        text/xml;
    gzip_vary on;

    # Security Headers
    add_header        X-XSS-Protection "1; mode=block" always;
    add_header        X-Content-Type-Options "nosniff" always;

    # Info
    add_header        X-Nginx-Cache-Status $upstream_cache_status;
    add_header        X-Server-Powered-By "Engintron";

    # Proxy Cache Settings
    proxy_cache_path  /var/cache/nginx/engintron_dynamic levels=1:2 keys_zone=engintron_dynamic:20m inactive=10m max_size=512m;
    proxy_cache_path  /var/cache/nginx/engintron_static levels=1:2 keys_zone=engintron_static:20m inactive=10m max_size=512m;
    proxy_temp_path   /var/cache/nginx/engintron_temp;

    ## Virtual Host Configs ##
    include /etc/nginx/conf.d/*.conf;
}

我要问的是，如果网站B在4-5-6秒内没有响应，我如何进行cUrl检查？还是有什么东西我可以增加我的配置？我还看到负载平均值不会超过1.5 (这是所有服务器的最大值)。

系统状态：

Processors: 8 CPU(s)

RAM: 31.19 GB

Memory Usage:
              total        used        free      shared  buff/cache   available
Mem:          31940        2155        2301         686       27484       28449
Swap:          1021          22         999

据我所见，在某个地方有一个限制，即如果到达X连接，就会减慢或超时，但不知道是这样。

在我的专用服务器上，除了来自nginx的配置之外，我在WHM Cpanel中拥有所有的默认设置配置。

我对服务器一点也不擅长，如果有人能指点我的话。

<#>编辑

仍然有一个站点关闭了(在修改超时为相同之后)，rest正在正常工作。

这是我的服务器上现在的连接：

Active connections: 4382 
server accepts handled requests
 457784 457784 478795 
Reading: 0 Writing: 4071 Waiting: 310 

通常最多有1000个活动连接..。

Answer 1

您将send_timeout (和其他几个超时)设置为5秒，但是调用外部网站的PHP代码等待7秒才能做出响应。很明显这不管用。你需要换一个或者两个都换。