и в какой локейшн этот запрос попадает из конфига? :)

ааа.точняк..блин .он не обрабатывается((9 лол ,я не проснулся еще

спасибо)

всем здравствуйте

всем привет. подскажите плиз. , http норм отрабатывает, https запрос отдает

This site can’t be reached

grafana.adtech.com unexpectedly closed the connection.

вот конфиг. нюанс : джинкс в доккере.. сслки все видит, все на месте.. в чем может быть ошибка... в локах почему то пусто...

server {
       listen 80;
       server_name grafana.adtech.com;
       location / {
              proxy_pass http://10.1.1.56:3000;
       }
}

server {
       listen 443 ssl;
       server_name grafana.adtech.com;

       access_log  /var/log/nginx/error_grafana.log;
       error_log  /var/log/nginx/error_grafana.log;

       index index.php index.html index.htm;

   client_max_body_size 200m;

   location / {
       proxy_pass http://10.1.1.56:3000;
       proxy_set_header X-Forwarded-Host $http_host;
       proxy_set_header X-Forwarded-Proto $scheme;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_http_version 1.1;
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection "upgrade";
       proxy_cache off;
       proxy_buffering off;
       proxy_read_timeout 86400s;
       proxy_send_timeout 86400s;
       proxy_set_header Connection '';
       chunked_transfer_encoding off;
   }  

       ssl_certificate      /etc/nginx/conf.d/ssl/grafana.adtech.com.crt;
       ssl_certificate_key  /etc/nginx/conf.d/ssl/grafana.adtech.com.key;
}

This site can’t be reached

grafana.adtech.com unexpectedly closed the connection.

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

спасибо, да.вроде аналогичная конфигурация без доккера работает, ну с минимальными отличиями..но  в доккере порт проброшен и обращения на 443 порт идут .лан .буду разбираться. благодарю)

Всем привет.
Есть nginx, который отдает статику.
Когда я нагружаю его через wrk, вижу такую картину.

$ wrk -t16 -c1000 -d30s ....
Running 30s test @ http://....
  16 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    77.09ms   52.79ms   1.16s    97.89%
    Req/Sec   808.15     39.97     1.01k    73.01%
  386359 requests in 29.98s, 313.19MB read
Requests/sec:  12887.79
Transfer/sec:     10.45MB

Максимальный запрос занимает больше секунды. Вопрос следующий, откуда беруться такие долгие реквесты на статике и как это можно поправить?

$ wrk -t16 -c1000 -d30s ....
Running 30s test @ http://....
  16 threads and 1000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    77.09ms   52.79ms   1.16s    97.89%
    Req/Sec   808.15     39.97     1.01k    73.01%
  386359 requests in 29.98s, 313.19MB read
Requests/sec:  12887.79
Transfer/sec:     10.45MB

попробуйте пул потоков

впрочем, он не снизит вам летенси от медленных запросов на статике, но снизит их импакт на остальные запросы к статике

Пробовал, ситуация не изменилась. Тем более у меня очень маленькая статика. Сами разработчики пишут, что данный механизм хорошо работает на блокирующих запросах, например, отдача больших файлов.
https://habrahabr.ru/post/260669/

любой запрос блокирующий.

если вы отправили read() в файловую систему на чтение файла в 5 байт, то он все равно может заблокироваться.

там же sendfile

Умолчание:  
sendfile off;

вообще я где то читал что nginx научился в asyncio с диска

sendfile у меня включен

но его бонус сомнительно полезен, потому что он работает только с директом