ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re[6]: Постоянные обрывы кон нектов



Спасибо за версии, но давайте мыслить дедуктивно.

Объем гадкого ответа рядом с размером в этой строчке конфига
listen       80 default sndbuf=64k;

Еще факт отфильтровал:
Добавил время ответа в лог (перед GET). Удивительная стабильность размера ответа и времени.

195.34.252.13 - - [15/Jul/2009:22:40:00 +0400] 30.001 GET /filmiki/4.tankista.i.sobaka.14.nad.shluzom.avi HTTP/1.0 ZZ 206 63461
195.34.252.13 - - [15/Jul/2009:22:40:07 +0400] 30.885 GET /filmiki/4.tankista.i.sobaka.14.nad.shluzom.avi HTTP/1.0 ZZ 206 62604
217.118.79.26 - - [15/Jul/2009:22:40:33 +0400] 34.833 GET /multiki/armenfilm.uh.ty.govorjaschaja.ryba.avi HTTP/1.0 ZZ 206 64434
195.34.253.17 - - [15/Jul/2009:22:40:44 +0400] 30.114 GET /multiki/burenka.iz.maslenkino.avi HTTP/1.0 ZZ 206 64032

 Если пытаться привязать к конфигу, у меня есть такая строчка:
    send_timeout           30s;

Решил сразу проверить, все верно:
listen       80 default sndbuf=32k;
   send_timeout           40s;

Пожалуйста:
80.73.6.156 - -      [15/Jul/2009:22:52:58 +0400] 40.000 GET /film/traktoristy.avi HTTP/1.0 ZZ 206 31040
195.34.252.13 - -   [15/Jul/2009:22:52:58 +0400] 40.003 GET /filmiki/4.tankista.i.sobaka.14.nad.shluzom.avi HTTP/1.0 ZZ 206 30252
95.104.171.181 - - [15/Jul/2009:22:53:02 +0400] 40.914 GET /multiki/koshkin.dom.1958.avi HTTP/1.0 ZZ 206 31456
79.139.154.17 - -   [15/Jul/2009:22:53:06 +0400] 40.002 GET /film/gu.ga.avi HTTP/1.0 ZZ 206 37272

Плюс у всех "Download Master" - проверил по другому логу. И все пытаются работать в 5 потоков.
все выше про сервер под фрюхой, nginx 0.8.5, нагрузка - 400Mbit

Тааак, присмотрелся к логу на линуксе (nginx/0.7.57, 800Mbit)
send_timeout           30s;
sendfile       off;
limit_req_zone $binary_remote_addr  zone=avi:10m   rate=2r/m;
listen       80 default sndbuf=64k;

85.172.38.82 - -     [15/Jul/2009:23:07:56 +0400] 30.958 GET /film/za.dvumja.zajcami.avi HTTP/1.0  206 129427
89.232.105.131 - - [15/Jul/2009:23:07:56 +0400] 30.073 GET /multiki/zolotoi.malchik.avi HTTP/1.0  206 130389
62.33.41.30 - -      [15/Jul/2009:23:07:58 +0400] 31.761 GET /film/aljoshkina.ljubov.avi HTTP/1.0  206 131107
93.185.24.117 - -  [15/Jul/2009:23:08:03 +0400] 30.903 GET /film/a.zori.zdes.tihie.1.avi HTTP/1.0  206 130385
91.204.196.31 - -  [15/Jul/2009:23:08:03 +0400] 30.098 GET /film/sluzhili.dva.tovarischa.avi HTTP/1.0  206 131108

Проблема в полный рост, просто размер мной не ожидаемый и долго маскировался.

Третий нагруженный сервер: фрюха, nginx/0.7.61 + patch  400 Mbit
sendfile       on;
limit_req_zone $binary_remote_addr  zone=avi:10m   rate=5r/m;
Проблема полностью отсутствует!!!

Еще два мало нагруженных сервера под фрюхой и sendfile off; - проблемы нет.

"Клиент" везде одинаковый, контент тоже - в этом смысле серверы в равных условиях.

Внимание, вопрос - какой правильный вывод?  :)



Антон.

2009/7/15 AleXXX V. NovikoFF <alexxx@xxxxxxxxx>
Hi!

Ну, например, Reget и DM при добавлении закачки, еще до начала скачивания,
делают HEAD, чтобы нарисовать юзеру длину файла и проверить, существует
ли он там вообще, его миме-тип и т.д.

Wed, 15 Jul 2009 12:47:32 +0400
"Dmitry Dedukhin" <dedukhin@xxxxxxx> писал(а):

> >>Обычно качалки делают HEAD к файлу, чтобы узнать длину ответа.
>
> Позвольте узнать, какие популярные качалки делают HEAD-запрос?
> Обычно, качалки делают запрос в первом потоке без Range, узнавая длину файла
> из ответа, потом создают дополнительные потоки с Range-запросами. При этом
> первый поток качает файл с начала и до того места, которое уже скачал другой
> поток, затем обрывает соединение.
>

--
Цитируйте предыдущую переписку, пожалуйста.
AleXXX V. NovikoFF <alexxx@xxxxxxxxx>
WWW: http://alexxx.ru/





--
Best regards,
Anton Kuznetsov.      


 




Copyright © Lexa Software, 1996-2009.