Добрый день.
Есть следующая конфигурация сервера:
server {
listen 80; ## listen for ipv4
listen 443 default_server ssl;
server_name localhost;
server_name_in_redirect off;
location = /loc {
if ($scheme = http) {
return 301
ный upstream_response_time?
On 3/25/20 7:09 PM, Evgeniy Berdnikov wrote:
> On Wed, Mar 25, 2020 at 09:48:10AM -0400, opan wrote:
>> Добрый день.
>>
>> В продолжение изучения проблемы обнаружили что в логе нжинкса
>> upstream_response_time - 41ms, а этот же запрос, если смо
жение должно касаться
только редких запросов
>
> 2) возможно, у вас работает буферизация запросов-ответов. попробуйте
"proxy_buffering off;" и "proxy_request_buffering off;" ?
>
> пн, 23 мар. 2020 г. в 14:01, opan :
>
> У нас есть одна площадка, нжинкс принимает за
У нас есть одна площадка, нжинкс принимает запросы и проксирует на бэкенд
через fcgi_pass. В логах нжинса мы видим upstream_response_time 40мс.
Появилась вторая площадка, мы принимаем там трафик и отправляем все на
первую площадку через proxy_pass. Так же логируем здесь
upstream_reponse_time и
1. Про ssl верно, мы замеряли сколько времени занимает установка соединения.
Это 20-30мс, не больше.
2. Пробовали, не помогает
Во всем этом самое странное, что время ответа через прокси и напрямую
примерно одинаковое, хотя если верить upstream_response_time оно должно быть
сильно больше через
Всем привет.
Проксируя запросы на fastcgi-бекенд, передаем в одном из заголовков $msec.
При этом приложение, сравнивая время, полученное в заголовке, и настоящее
для него, дает аномальный дифф - до 40мс внутри локалки, а иногда и
отрицательное, до -5мс.
Внутри локальной сети пакеты бегают
