Django uwsgi无法处理超过一分钟的请求

我有一个Django应用程序，它通过uwsgi在docker容器中提供服务。我准备了一个自定义视图，只是为了重现我提到的问题。它看起来就像下面：

def get(self, request):
    logger = logging.getLogger('ReleaseReport')
    logger.critical('Entering and sleeping')
    time.sleep(180)
    logger.critical('Awaking')

    return Response({'response': 'anything'})

它（有意）做的唯一事情就是记录消息，睡眠3分钟，然后再记录另一条消息

下面是我尝试从Firefox/Chrome/PyCharm的rest API客户端访问视图后日志文件的工作方式：

spawned uWSGI worker 9 (pid: 14, cores: 1)
spawned uWSGI worker 10 (pid: 15, cores: 1)
spawned uWSGI http 1 (pid: 16)
CRITICAL 2018-08-31 12:10:37,658 views Entering and sleeping
CRITICAL 2018-08-31 12:11:37,742 views Entering and sleeping
CRITICAL 2018-08-31 12:11:38,687 views Awaking
[pid: 10|app: 0|req: 1/1] 10.187.133.2 () {36 vars in 593 bytes} [Fri Aug 31 12:10:37 2018] GET /api/version/ => generated 5156 bytes in 61229 msecs (HTTP/1.1 200) 4 headers in 137 bytes (1 switches on core 0)
CRITICAL 2018-08-31 12:12:37,752 views Entering and sleeping
CRITICAL 2018-08-31 12:12:38,784 views Awaking
[pid: 15|app: 0|req: 1/2] 10.187.133.2 () {36 vars in 593 bytes} [Fri Aug 31 12:11:37 2018] GET /api/version/ => generated 5156 bytes in 61182 msecs (HTTP/1.1 200) 4 headers in 137 bytes (1 switches on core 0)
CRITICAL 2018-08-31 12:13:38,020 views Entering and sleeping
CRITICAL 2018-08-31 12:13:38,776 views Awaking
[pid: 10|app: 0|req: 2/3] 10.187.133.2 () {36 vars in 593 bytes} [Fri Aug 31 12:12:37 2018] GET /api/version/ => generated 5156 bytes in 61034 msecs (HTTP/1.1 200) 4 headers in 137 bytes (1 switches on core 0)

一分钟后，视图似乎再次执行，另一分钟后，第三次执行。此外，日志说它是HTTP 200，但客户端没有收到数据，只是说在几分钟后无法加载数据（取决于客户端）。然而，日志中的第一个HTTP200在客户端放弃之前发生得更早

有什么线索可能导致这个问题吗？这是我的uwsgi.ini：

[uwsgi]

http = 0.0.0.0:8000
chdir = /app
module = web_server.wsgi:application
pythonpath = /app

static-map = /static=/app/static

master = true
processes = 10
vacuum = true

Dockerfile

命令如下：

/usr/local/bin/uwsgi --ini /app/uwsgi.ini

在我的实际应用程序中，它会导致客户端认为请求失败，但由于它实际执行并完成了3次，所以数据库中有3条记录。将工作进程数更改为1不会有太大变化。它不是在一分钟内再次生成视图，而是在前一个视图完成后生成

我的配置有什么问题

编辑：

我稍微改变了我的视图，它现在接受睡眠时间参数，如下所示：

def get(self, request, minutes=None):
    minutes = int(minutes)
    original_minutes = minutes
    logger = logging.getLogger(__name__)
    while minutes > 0:
        logger.critical(f'Sleeping, {minutes} more minutes...')
        time.sleep(60)
        minutes -= 1

    logger.critical(f'Slept for {original_minutes} minutes...')
    return Response({'slept_for': original_minutes})

现在，卷发：

> curl http://test-host/api/test/0
{"slept_for":0}

> curl http://test-host/api/test/1
{"slept_for":1}

> curl http://test-host/api/test/2
curl: (52) Empty reply from server

在日志中：

CRITICAL 2018-08-31 14:23:36,200 views Slept for 0 minutes...
[pid: 10|app: 0|req: 1/14] 10.160.43.172 () {28 vars in 324 bytes} [Fri Aug 31 14:23:35 2018] GET /api/test/0 => generated 15 bytes in 265 msecs (HTTP/1.1 200) 4 headers in 129 bytes (1 switches on core 0)
CRITICAL 2018-08-31 14:23:42,878 views Slept for 0 minutes...
[pid: 10|app: 0|req: 2/15] 10.160.43.172 () {28 vars in 324 bytes} [Fri Aug 31 14:23:42 2018] GET /api/test/0 => generated 15 bytes in 1 msecs (HTTP/1.1 200) 4 headers in 129 bytes (1 switches on core 0)
CRITICAL 2018-08-31 14:23:46,370 views Sleeping, 1 more minutes...
CRITICAL 2018-08-31 14:24:46,380 views Slept for 1 minutes...
[pid: 10|app: 0|req: 3/16] 10.160.43.172 () {28 vars in 324 bytes} [Fri Aug 31 14:23:46 2018] GET /api/test/1 => generated 15 bytes in 60011 msecs (HTTP/1.1 200) 4 headers in 129 bytes (1 switches on core 0)
CRITICAL 2018-08-31 14:27:06,903 views Sleeping, 2 more minutes...
CRITICAL 2018-08-31 14:28:06,963 views Sleeping, 1 more minutes...
CRITICAL 2018-08-31 14:29:06,995 views Slept for 2 minutes...
[pid: 9|app: 0|req: 1/17] 10.160.43.172 () {28 vars in 324 bytes} [Fri Aug 31 14:27:06 2018] GET /api/test/2 => generated 15 bytes in 120225 msecs (HTTP/1.1 200) 4 headers in 129 bytes (1 switches on core 0)

如果我使用相同的命令来测试运行在

manage.py runserver

下的服务器，它每次都会响应—无论我是睡眠2分钟还是10分钟。因此，这不是客户的过错。 我把harakiri改成了3600，没有变化

EDIT2（我的Dockerfile）：

---

这实际上是Dockerfile的问题。以前我在requirements.txt中有uWSGI，所以它是通过

pip install

安装的
当我删除它并将

uwsgi-python3

添加到

apk add

后，现在一切都很好

---

不知道这有什么关系（其他一切都很好），但它解决了我的问题。

过了一段时间，浏览器“放弃”，不再听取响应，不管服务器是否提供响应。此外，Django与一组工作人员一起工作，如果我没记错的话，他们可以处理请求。因此，它将限制并发执行的请求数。因此，如果上述情况属实，op可以尝试curl来确认。我尝试了不同的客户端，包括PyCharm的内置和失眠，但你的观点是正确的。看起来浏览器和客户端正在重试。他们似乎无法读取HTTP响应，只是在重试。Curl没有，它只是说

empyreply from server

。您的dockerfile是什么样子的？

FROM python:3.7.0-alpine

ADD . /app

RUN set -ex \
    && apk add mysql-dev \
               pcre-dev \
    && apk add --no-cache --virtual .build-deps \
            gcc \
            make \
            libc-dev \
            musl-dev \
            linux-headers \
            libffi-dev \
    && pip install --no-cache-dir -r /app/requirements.txt \
    && runDeps="$( \
            scanelf --needed --nobanner --recursive /venv \
                    | awk '{ gsub(/,/, "\nso:", $2); print "so:" $2 }' \
                    | sort -u \
                    | xargs -r apk info --installed \
                    | sort -u \
    )" \
    && apk add --virtual .python-rundeps $runDeps \
    && apk del .build-deps

WORKDIR /app

RUN mkdir -p static
RUN python manage.py collectstatic --clear --noinput

EXPOSE 8000

CMD ["/usr/local/bin/uwsgi", "--ini", "/app/uwsgi.ini"]