Comments 5
TCP_NODELAY — это не кеширование, это попытка добить размер TCP пакета до размера MSS чтобы избежать большого пакетрейта.
Все так, просто Сергей неточно выразился, да и детали TCP протокола за пределами данного доклада.
А выложен ли код бенчмарков? Особенно интересно в части ускорения через TCP_NODELAY. Хотелось бы вопроизвести руками.
Попросил Сергея ответить:
Самой главный недостаток расшифровки, который я пропустил/, заключается в том, что на видео вырезано начало. Где я объясняю назначение этой презентации. Это не расссказ про TCP стек. И это на самом деле не рассказ про новый HttpClient на новом протоколе HTTP/2. Просто после того как раньше мы сделали различные презентации про производительность, я получил кучу запросов, что все эти правила и методологии это хорошо, а неплохо было бы показать это на реальном живом проекте. Вот я и взял свой последний завершенный на тот момент проект и сделал историю как его разгонял. Чтобы показать весь процесс на отдельно взятом проекте. Такое вот пропущенное введение.

Если вернутся к вопросу.
Почему в данном случае это не нужно (сорсить бенчи):
— NODELAY клэш весьма чувствителен к размеру окна и размеру передаваемых данных. За последний год клиент развивался и менялся и нет накакой гарантии (и никто не будет проверять), что этот клэш существует в данный момент. Да даже год назад данная проблема не обязательно бы повторилась после всей кучи последующих оптимизаций, который конечно же поменяли размеры и интенсивность траффика. Sic! Перформансные оптимизации — не коммутативны! (и не ассоциативны тоже).
— За год клиент менялся в плане внешнего API и ресурсов поддерживать банальную компилируемость бенчей нет. Так что никто из performance team не проверял как они работают сейчас, кроме уже самих авторов клиента, который бенч получили, а что они там с ним делают неизвестно.
— В природе гуглится куча статей с бенчми на NODELAY, гораздо более информативных чем рассказано в данном докладе.

Почему в данном случае это нереально:
— выклыдывание в открытый доступ любого кода написанного мной для текущего работадателя требует согласования с юристами. Как минимум причина «для доклада» — не очень хорошее бизнес обоснование.

Само собой в общем случае — выкладывать бенчи к докладу — это хорошая идея, и когда это возможно я всегда так и делал. Но не в данном конкретном примере.

Вдогонку. Стоит добавить.
Вообще проблема Nagel VS delayed ACK правильным образом должна решаться не опцией TCP_NODELAY, а опцией TCP_QUICKACK.
К сожалению, когда писали Java networking такой опции еще не существовала в природе.
Поэтому на момент написания HttpClient'а такое опции и не было в Java.
У нас есть фича реквест — добавить в java.net все новые опции. И он был сделан.
Но TCP_QUICKACK успела попасть только в Java10.
see: docs.oracle.com/javase/10/docs/api/jdk/net/ExtendedSocketOptions.html

Классная статья.

Интересно было бы увидеть замеры по изменению поведения flow control на соединении с latency скажем 300ms и прокачкой в 50кбит с потерями на уровне 5% (привет EDGE и коннект Сидней -> Лондон или вроде того).

flow control все таки немного не для localhost создавался.
Насколько я понимаю для loopback вполне легальным будет послать WINDOW_UPDATE с (2^31)-1
Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

25 March 2012

Location

Россия

Website

jugru.org

Employees

51–100 employees

Registered

22 August 2013

Habr blog