Comments 5
TCP_NODELAY — это не кеширование, это попытка добить размер TCP пакета до размера MSS чтобы избежать большого пакетрейта.
А выложен ли код бенчмарков? Особенно интересно в части ускорения через 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
Интересно было бы увидеть замеры по изменению поведения flow control на соединении с latency скажем 300ms и прокачкой в 50кбит с потерями на уровне 5% (привет EDGE и коннект Сидней -> Лондон или вроде того).
flow control все таки немного не для localhost создавался.
Насколько я понимаю для loopback вполне легальным будет послать WINDOW_UPDATE с (2^31)-1
Sign up to leave a comment.
Повесть о том, как один инженер HTTP/2 Client разгонял