On 04 Nov 2013, at 18:09, Anatoly Mikhailov <anat...@sonru.com> wrote:
>
> On 30 Oct 2013, at 12:08, Maxim Dounin <mdou...@mdounin.ru> wrote:
>
>> Hello!
>>
>> On Mon, Oct 28, 2013 at 12:34:33PM -0400, buddha wrote:
>>
>>> Привет всем.
>>> Знаю что вопрос уже обсуждался - почитал, попробовал - не выходит.
>>>
>>> Есть проблема с медленной отдачей статики. Что это значит:
>>>
>>> Отдача файла(js) ~40kb за 300-400ms
>>> на drive.ru или ya 40kb за 70-90ms
>>>
>>> Т.е. разница в разы. и она ощутима.
>>>
>>> ping до сервера ~70ms
>>> до drive и ya ~ 20-30ms
>>>
>>> отдает Nginx, config:
>>>
>>> location / {
>>> sendfile on;
>>> access_log off;
>>> expires 4M;
>>>
>>> root /var/www/static
>>> }
>>>
>>> сервер находится у хетцнера.
>>>
>>> Подскажите как можно приблизить скорость отдачи к drive или ya.
>>> Если сервер, диск(хотя iowait 0.01-0.05), то подскажите на что его можно
>>> заменить
>>
>> Судя по цифрам, то, что у вас получается - это в первую очередь
>> результат большого RTT + работы механизмов Congestion Control
>> протокола TCP.
>>
>> Можно пытаться походить в сторону тюнинга initial congestion
>> window size. Но, строго говоря, много это всё равно не даст -
>> где-то пару round trip'ов можно сэкономить при использовании
>> сейчас усиленно продвигаемого initial cwnd в 10 пакетов (и чем
>> больше ответ - тем меньше разница). Ну и на всякий случай
>> напомню, что с тюнингом таких вещей следует быть осторожным, т.к.
>> подобные действия отражаются на всех в сети. Прежде, чем
>> ковыряться - лучше как минимум ознакомиться с теоретической
>> стороной вопроса.
>
> Максим, разве Google не провел исследования, по результатам
> которых они подняли icwnd до 10 на своих серверах?
>
> В последних версиях Linux kernel icwnd уже 10 по умолчанию
> и может дать обратный эффект только в очень редких случаях
> на сегодняшний день.
>
> TCP fast open в kernel 3.6+ следующей шаг, в который Google
> вкладывает силы и деньги.
Насколько мне известно, TCP Congestion window имеет смысл
при согласовании окон получателя и отправителя. ICWND 2/3 были
установлены по умолчанию много лет назад во времена dial-up.
TCP Slow Start обязательно иметь включенным, но start after idle
нет смысла оставлять 1 сек, как и размер окна 2/3.
Мы уделяли большое внимание оптимизации TCP/IP стэка, результаты
ниже. В течение длительного времени я не заметил побочных эффектов,
возможно они и есть. Ваше мнение?
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_sack = 0
net.ipv4.tcp_timestamps = 0
net.core.wmem_max = 256960
net.core.rmem_max = 256960
net.core.wmem_default = 256960
net.core.rmem_default = 256960
net.ipv4.tcp_wmem = 4096 87380 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
>
>>
>> Вообще, IMHO, в первую очередь имеет смысл смотреть за тем, чтобы
>> с клиентами обеспечивались постоянные соединения. В nginx'е они
>> по умолчанию включены, но лишний раз проверить не помешает. В
>> частности - посмотреть на директиву keepalive_timeout и убедиться,
>> что там никто не написал 0 в попытке поэкономить соединения.
>>
>> --
>> Maxim Dounin
>> http://nginx.org/en/donation.html
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
