Re: Проксирование, буфер, лаги
Спасибо за ответ. Буферизация конечно включена, мне просто показалось что желаемое поведение (одновременный прием от апстрима и отправка клиенту) происходит только при выключенной буферизации. Размер буфера в несколько десятков кб роли не играет, это почти одновременно. У нас в основном картинки по несколько сот кб. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285149,285155#msg-285155 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Проксирование, буфер, лаги
Hello! On Wed, Aug 07, 2019 at 12:56:18PM -0400, rihad wrote: > Просто эта цитата в доках на английском говорит, что такое бывает при > выключенном буферинге. Приведённая цитата говорит, что бывает при _выключенной_ буферизации. Что бывает при включённой - написано в предыдущем абзаце. Принципиальный момент, на самом деле, приблизительно один: - В случае выключенной буферизации отправка будет происходить сразу после получения данных от бэкенда. Включая сброс буферов всяких других уровней, как то gzip или SSL. Если же буферизация включена - nginx будет ждать заполнения очередного буфера, и только после его заполнения будет пытаться отправить его содержимое клиенту. Поэтому буферизированное проксирование эффективнее, но может быть непригодно, если HTTP-ответы используются для потоковой отправки данных с небольшой скоростью (и тогда буферизацию имеет смысл отключать). Кроме того, стоит помнить, что: - В случае выключенной буферизации nginx не будет пытаться прочитать целиком ответ от бэкенда, а вместо этого прекратит чтение, как только у него закончится буфер и не будет возможности отправить содержимое этого буфера клиенту. В случае со включённой буферизацией - похожего поведения можно добиться, установив proxy_max_temp_file_size в 0 (с точностью до того, что при этом будет используется не один буфер, а много). - При выключенной буферизации невозможно сохранения ответа на диск, и соответственно не будет работать кэширование и proxy_store. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Проксирование, буфер, лаги
Просто эта цитата в доках на английском говорит, что такое бывает при выключенном буферинге. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285149,285153#msg-285153 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Проксирование, буфер, лаги
rihad писал 2019-08-07 17:09: Меня вот это немного смутило: "When buffering is disabled, the response is passed to a client synchronously, immediately as it is received. nginx will not try to read the whole response from the proxied server. " http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffering Получается когда buffering включен, то наоборот, контент читается полностью перед началом отдачи клиенту. Нет. Ответ начинает отдаваться клиенту сразу по получении его от бэкенда. Зачем ждать конца? Это 2 независимых процесса, работающих с максимально возможной скоростью * ответ от бэкенда вычитывается быстро * полученный от бэкенда ответ - передаётся клиенту по мере готовности клиента его принять. -- Best regards, Andrey A. Kopeyko ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Проксирование, буфер, лаги
Меня вот это немного смутило: "When buffering is disabled, the response is passed to a client synchronously, immediately as it is received. nginx will not try to read the whole response from the proxied server. " http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffering Получается когда buffering включен, то наоборот, контент читается полностью перед началом отдачи клиенту. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285149,285150#msg-285150 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Проксирование, буфер, лаги
Допустим если включено кеширование через proxy_cache, а также включено proxy_buffering (по умолчанию). Что происходит когда клиент запрашивает ресурс которого нет в кеше? Он сначала полностью скачивается из апстрима, кешируется, и только потом начинает отдаваться клиенту? И если таких уровней апстримов 2 или более, то лаг получения контента клиентом увеличивается грубо говоря в 2 или более раз? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285149,285149#msg-285149 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Иногда в логах проскакивает SSL write() failed
Hello!
On Mon, Aug 05, 2019 at 12:14:49PM -0400, grey wrote:
> Приветствую всех.
>
>
> Прикрутил к одному сайту защищенный протокол. Не сразу заметил, что во время
> наплыва посетителей сайт стал сильно тормозить, а в логах появляется
> ошибка:
>
> 2019/08/05 17:32:57 [crit] 1832#2988: *131089 SSL_write() failed (10053:
> Программа на вашем хост-компьютере разорвала установленное подключение)
> while sending response to client, client: 5.18.*.*, server: ***.ru, request:
> "GET /logo.jpg HTTP/1.1", upstream: "http://127.0.0.1:81/logo.jpg";, host:
> "www.***.ru"
>
> Версия nginx под Windows последняя 1.17.2. Сервер физический, но слабенький.
> Если отключить шифрование, то все летает.
> upstream: "http://127.0.0.1:81"; - это Апач. Может не хватает ресурсов
> процессора на шифрование трафика или я где-то накосячил?
Если я правильно понимаю, такая ошибка может (и должна) возникать,
если клиент закрывает соединение в процессе получения ответа.
Уровень логгирования в данном случае завышен в случае
SSL-соединений, так как SSL-код не учитывает особенности виндов.
Какой-то такой патч должен проблему закрыть, снизив уровень
логгирования до стандартного в подобных ситуациях:
# HG changeset patch
# User Maxim Dounin
# Date 1565182777 -10800
# Wed Aug 07 15:59:37 2019 +0300
# Node ID 50a68c37eb3b399aca25ffa06527f263d1961e07
# Parent fcd92ad76b7bb04b46c4b8fdfe14b6065acadf7d
SSL: lowered log level for WSAECONNABORTED errors on Windows.
Winsock uses ECONNABORTED instead of ECONNRESET, for normal connections
this is already handled since baad3036086e.
Reported at
http://mailman.nginx.org/pipermail/nginx-ru/2019-August/062363.html.
diff --git a/src/event/ngx_event_openssl.c b/src/event/ngx_event_openssl.c
--- a/src/event/ngx_event_openssl.c
+++ b/src/event/ngx_event_openssl.c
@@ -2814,6 +2814,9 @@ ngx_ssl_connection_error(ngx_connection_
if (sslerr == SSL_ERROR_SYSCALL) {
if (err == NGX_ECONNRESET
+#if (NGX_WIN32)
+|| err == NGX_ECONNABORTED
+#endif
|| err == NGX_EPIPE
|| err == NGX_ENOTCONN
|| err == NGX_ETIMEDOUT
--
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Не передается Last Modified
Разобрался. Оказалось далеко в коде этот заголовок устанавливался на текущую дату. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285137,285139#msg-285139 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
