编辑

Question

快速摘要

我正在将HTTP服务器作为服务在docker swarm上运行。我正在使用curl循环运行来测试请求时间。如果我使用任何代理将流量定向到服务，则会随机出现1秒的延迟。如果我使用的是HTTP服务器在swarm上发布的端口，则一切正常。如果我没有蜂拥而来运行相同的服务（使用docker run）并使用相同的代理-时间也可以。

您得到了这样的效果吗？有人对如何摆脱它有任何提示吗？

详细的说明和脚本

这是我正在使用的简单HTTP服务docker-compose文件：

version: '3.5'

services: 
app:
    image: nginx:latest
    networks:
      - proxy
    ports:
      - 48091:80
    deploy:
      placement:
        constraints:
          - node.hostname == some-node-name
      labels:
        - "traefik.docker.network=proxy"
        - "traefik.port=80"
        - "traefik.frontend.rule=Host:some.test.url.com"

networks:
  proxy:
    external: true

默认设置是使用Nginx作为群集之外的主要代理，将测试域请求定向到在群集内作为服务运行的Traefik代理，并将请求重定向到测试HTTP服务。当然，在这种情况下不使用已发布的48091端口。

我正在使用简单的脚本从本地网络中的curl测试请求时间：

#!/bin/

for i in {1..1000}; do
    curl -g -so /dev/null -w '%{time_total}\n' http://some.test.url.com
done

curl记录的正常总请求时间约为0,006ms，但有时会增加1秒。有时，所有1000个请求都没有延迟地运行，但是在下一次运行中，有2％或6％的“长”时间。有时延迟是单个的，但通常服务会“锁定”一段时间，而且我连续收到很多长请求。

我首先想到的是Traefik引起的，所以我在集群上发布了48091端口，并直接绕开了Traefik，直接将主要Nginx的请求定向到该端口。结果是完全一样的-许多长请求。

下一个测试直接在Traefik上运行-没有第一个Nginx。没有变化-仍然坏了。

但是

在没有任何代理的情况下测试服务-仅将curl请求定向到群集节点上的48091端口似乎正常。我运行了数十万个请求，但没有一个被锁定。

此外，如果我没有大批运行HTTP服务-在之前使用的同一台计算机上使用docker run -p 48091:80 nginx:latest并使用前Nginx 进行测试-一切都还可以。

总结

如果我在一个集群中运行服务并在其之前使用 any 代理，则会出现问题。我可以无群运行，或者我直接使用已发布的端口-一切正常。

由于我们正计划运营一个大型网站，而这看起来像是一门止步不前的工具，因此希望对这个问题有所帮助。在启动之前切换到Kubernetes是不现实的：（

编辑

我微调了测试脚本，以获取有关curl定时的精确信息：

#!/bin/bash URL="http://some.test.url.com" OUT="%{time_total} | lookup: %{time_namelookup} | connect: %{time_connect} | appconnect: %{time_appconnect} | pretransfer: %{time_pretransfer} | redirect: %{time_redirect} | starttransfer: %{time_starttransfer}\n" for i in {1..10000}; do curl -g -so /dev/null -w "$OUT" $URL done

现在，针对Nginx-> Swarm的测试输出（仅长请求）如下所示：

1.027 | lookup: 0.004 | connect: 0.005 | appconnect: 0.000 | pretransfer: 0.005 | redirect: 0.000 | starttransfer: 1.027 1.028 | lookup: 0.004 | connect: 0.005 | appconnect: 0.000 | pretransfer: 0.005 | redirect: 0.000 | starttransfer: 1.027 1.047 | lookup: 0.004 | connect: 0.005 | appconnect: 0.000 | pretransfer: 0.005 | redirect: 0.000 | starttransfer: 1.047 1.046 | lookup: 0.004 | connect: 0.005 | appconnect: 0.000 | pretransfer: 0.005 | redirect: 0.000 | starttransfer: 1.046 1.049 | lookup: 0.004 | connect: 0.005 | appconnect: 0.000 | pretransfer: 0.005 | redirect: 0.000 | starttransfer: 1.049 1.010 | lookup: 0.004 | connect: 0.005 | appconnect: 0.000 | pretransfer: 0.005 | redirect: 0.000 | starttransfer: 1.009 1.009 | lookup: 0.004 | connect: 0.005 | appconnect: 0.000 | pretransfer: 0.005 | redirect: 0.000 | starttransfer: 1.009 1.009 | lookup: 0.004 | connect: 0.005 | appconnect: 0.000 | pretransfer: 0.005 | redirect: 0.000 | starttransfer: 1.008

因此，延迟始终在“ starttransfer”上。如果我正确理解这一点：https://blog.cloudflare.com/a-question-of-timing/，则意味着在Nginx和swarm中的服务之间传递GET请求存在一些问题。

通过代理到达群集部署的http服务时，随机延迟1秒

编辑

0 个答案: