Тело ответа пирамидного потока

Я нашел проблему. Оказывается, мой код приложения в порядке, и проблема заключается в официантке и nginx:

1. Официантка, веб-сервер, используемый Pyramid по умолчанию, буферизует все выходные данные фрагментами по 18 000 байт (см. эту проблему для подробностей).

2. Источник проблемы был скрыт от меня nginx, веб-сервером, который я поставил перед своим приложением Pyramid, который также буферизует ответы.

(1) может быть решена либо:

• Настройка официантки с помощью send_bytes = 1 в вашем .ini-файле. Это устраняет проблему потоковой передачи, но делает все ваше приложение очень медленным. Как уже упоминалось @Zitrax, вы можете восстановить некоторую скорость с более высокими значениями, но любое значение выше 1 может привести к тому, что сообщения застрянут в буфере.

• Переходим на ганикорн. Я не знаю, использует ли gunicorn меньший буфер или он ведет себя лучше с app_iter, но это сработало и ускорило мое приложение.

(2) можно решить, настроив nginx на отключение буферизации для ваших потоковых маршрутов.

Вам нужно установить proxy_buffering off в вашей конфигурации nginx. Этот параметр применяется к сайтам, размещенным через proxy_pass. Если вы не используете proxy_pass, вам может понадобиться другая настройка.

• Вы можете настроить nginx для динамического включения/отключения буферизации для каждого ответа на основе заголовков запроса, как показано в этом вопросе по теме (хорошее решение для EventSource/Server-Sent Events)

• В качестве альтернативы вы можете настроить это в блоке location в вашей конфигурации nginx. Это хорошо, если вы используете что-то помимо EventSource и не ожидаете получить конкретный заголовок, или если вы используете EventSource, но хотите отладить ответ с простой вкладки браузера, куда вы не можете отправить Accept заголовок в вашем запросе.

Некоторое время назад я сделал несколько тестов, чтобы попробовать Event Source/Server Sent Events. Я только что проверил, и он все еще отлично работает с Pyramid 1.5a.

@view_config(route_name = 'events')
def events(request):
    headers = [('Content-Type', 'text/event-stream'),
               ('Cache-Control', 'no-cache')]
    response = Response(headerlist=headers)
    response.app_iter = message_generator()
    return response

def message_generator():
    socket2 = context.socket(zmq.SUB)
    socket2.connect(SOCK)
    socket2.setsockopt(zmq.SUBSCRIBE, '')
    while True:
        msg = socket2.recv()
        yield "data: %s\n\n" % json.dumps({'message': msg})

Полный пример здесь: https://github.com/antoineleclair/zmq-sse-chat . Взгляните на https://github.com/antoineleclair/zmq-sse-chat/blob/master/sse/views.py.

Я точно не знаю, почему у меня работает, а у вас нет. Возможно, это заголовки. Или два '\n' после каждого сообщения. Кстати, если вы правильно посмотрите на спецификацию источника событий, вы должны ставить перед каждым новым событием префикс data: и использовать \n\n в качестве разделителя событий.

Если вы не укажете какой-либо рендерер для своего представления, вы должны вернуть объект Response. Объект Pyramid Response имеет специальный аргумент app_iter для возврата итераторов. Итак, вы должны сделать это следующим образом:

import time
from pyramid.response import Response


@view_config(route_name='iter_test')
def iter_test(request):

    def test_iter():
        for _ in range(5):
            yield str(time.time())
            print time.time()
            time.sleep(1)

    return Response(app_iter=test_iter())

Я также немного отредактировал ваш код, чтобы сделать его более читаемым.

ОБНОВЛЕНИЕ

Вместо этого я пробовал return Response(app_iter=test_iter()), который, по крайней мере, не выдает ошибку, но не передает ответ - он ждет, пока генератор завершит работу, прежде чем вернуть ответ моему браузеру.

Думаю проблема в буферизации. Попробуйте отправить действительно большой итератор.