Re: Медленная отдача статики

[Anatoly Mikhailov]

On 04 Nov 2013, at 18:09, Anatoly Mikhailov <anatoly at sonru.com> wrote:

> 
> On 30 Oct 2013, at 12:08, Maxim Dounin <mdounin at 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 at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20131104/0cfbc2d9/attachment.html>