Comments 59
У вас скорее всего пользователи все из России, и latency весьма небольшой, и доменов немного :). В таком случае, вероятно, действительно будет играть намного бОльшую роль ширина канала, чем что-то ещё.
Пользователи у нас из самых разных мест, но мы стараемся для всех них сохранять как можно меньший latency и развиваем CDN.
Население на большей части территории России получает интернет по спутниковым каналам, поэтому высокий latency и низкая пропускная способность всё еще значимые факторы в нашей стране…
Странный результат (отсутствие ускорения). Имхо, нужно смотреть waterfall диаграмму загрузки контента и сравнивать на разных версиях протокола.
>Однако в SPDY мы нашли для себя неожиданный профит. За счет того, что многие клиенты перестали создавать на каждый файл по соединению, этих соединений стало заметно меньше, а значит, наши процессоры стали меньше нагружаться. То есть какая-никакая, а экономия есть.
Вот это неожиданность! В протоколе для мультиплексирования нашли мультиплексирование!
Вот это неожиданность! В протоколе для мультиплексирования нашли мультиплексирование!
Это экономия не за счет мультиплексирования, а за счет меньшего количества файловых дескрипторов для той же нагрузки.
Не понял, а как SPDY может влиять на количество файловых дескрипторов?
соединение > сокет > файловый дескриптор
Вместо четырех http соединений браузер открывает всего-навсего одно.
Неожиданно потому что у нас nginx использует epoll, а у него асимптотическая сложность O(1) от количества сокетов. Т.е. изменение количества соединений не должно было повлиять на скорость обработки epoll и утилизацию системы. Ан нет;-)
Неожиданно потому что у нас nginx использует epoll, а у него асимптотическая сложность O(1) от количества сокетов. Т.е. изменение количества соединений не должно было повлиять на скорость обработки epoll и утилизацию системы. Ан нет;-)
Теперь понял
>Т.е. изменение количества соединений не должно было повлиять на скорость обработки epoll и утилизацию системы.
а с чего вы решили, что у вас будут потребляться ресурсы именно на epoll?
большее число fd => больше событий => больше сисколлов => больше контекстсвитчей.
а с чего вы решили, что у вас будут потребляться ресурсы именно на epoll?
большее число fd => больше событий => больше сисколлов => больше контекстсвитчей.
Ну на самом деле в данном случае большее число fd не означает больше событий.
У нас как был определенный набор статических файлов, так и остался. Как была аудитория из N пользователей так и осталась. Если оценить нагрузку по пропускной способности, т.е. в запросах в секунду, то она какой была такой и осталось. Количество событий в единицу времени тоже должно было остаться тем же. Всем пользователям нужно запрашивать все те же файлы, только по другому протоколу, не по HTTP, а по SPDY, с той же интенсивностью.
Конечно, в spdy есть мультиплексирование и в сокет может прилететь сразу два запроса, а вычитать мы можем их за один read(). Насколько такая ситуация частая? Мне кажется что она довольно редкая, и такая схема не должна была сэкономить много ресурсов.
Можно еще сделать буфферизованную запись в spdy-соединение чтобы уменьшить количество вызовов write(), но это опять же очень спорный момент! Станет ли лучше из-за этого? Ведь теперь необходимо задерживать ответ накапливая хоть какой-то буффер.
Ну и сдается мне декодер/енкодер spdy-протокола несколько сложней аналогичного для http, и должен требовать больше ресурсов.
У нас как был определенный набор статических файлов, так и остался. Как была аудитория из N пользователей так и осталась. Если оценить нагрузку по пропускной способности, т.е. в запросах в секунду, то она какой была такой и осталось. Количество событий в единицу времени тоже должно было остаться тем же. Всем пользователям нужно запрашивать все те же файлы, только по другому протоколу, не по HTTP, а по SPDY, с той же интенсивностью.
Конечно, в spdy есть мультиплексирование и в сокет может прилететь сразу два запроса, а вычитать мы можем их за один read(). Насколько такая ситуация частая? Мне кажется что она довольно редкая, и такая схема не должна была сэкономить много ресурсов.
Можно еще сделать буфферизованную запись в spdy-соединение чтобы уменьшить количество вызовов write(), но это опять же очень спорный момент! Станет ли лучше из-за этого? Ведь теперь необходимо задерживать ответ накапливая хоть какой-то буффер.
Ну и сдается мне декодер/енкодер spdy-протокола несколько сложней аналогичного для http, и должен требовать больше ресурсов.
в принципе, на этот счёт меня сомнения и терзали.
на свежую голову пришёл более правдоподобный вариант: spdy — бинарный, а http — текстовый.
на свежую голову пришёл более правдоподобный вариант: spdy — бинарный, а http — текстовый.
Все что вы описали, сущая мелочь на фоне того, что происходит в сети.
Не забывайте, что имея 6 соединений вместо 1, вы также получаете в 6 раз больший суммарный объем всех буферов, 6-ти кратный размер суммарного окна, а также на 6 соединениях потеря одного пакета имеет в 6 раз меньший эффект. А кроме того, в условиях конкуренции за ресурсы, причем как за пропускную способность, так и за события — как способ получения таймфрейма на обработку, 6 соединений получат в 6 раз больше ресурсов.
Экономия соединений интересна в целях снижания общей нагрузки на сетевую инфраструктуру. И я так понимаю, исключительно о данном контексте идет речь, а не о том, что это дает какое-то ускорение.
Основное ускорение в SPDY достигается приемущественно за счет экономии на последовательных TCP+TLS хэндшейках, но в случае Яндекса, это не было достигнуто из-за того, что имел место быть шардинг, и клиент вынужден был запрашивать страницу с одного сервера, а потом опять соединяться с другим уже для запроса статики.
Об этом и создатели протокола пишут:
Не забывайте, что имея 6 соединений вместо 1, вы также получаете в 6 раз больший суммарный объем всех буферов, 6-ти кратный размер суммарного окна, а также на 6 соединениях потеря одного пакета имеет в 6 раз меньший эффект. А кроме того, в условиях конкуренции за ресурсы, причем как за пропускную способность, так и за события — как способ получения таймфрейма на обработку, 6 соединений получат в 6 раз больше ресурсов.
Экономия соединений интересна в целях снижания общей нагрузки на сетевую инфраструктуру. И я так понимаю, исключительно о данном контексте идет речь, а не о том, что это дает какое-то ускорение.
Основное ускорение в SPDY достигается приемущественно за счет экономии на последовательных TCP+TLS хэндшейках, но в случае Яндекса, это не было достигнуто из-за того, что имел место быть шардинг, и клиент вынужден был запрашивать страницу с одного сервера, а потом опять соединяться с другим уже для запроса статики.
Об этом и создатели протокола пишут:
Don’t shard hostnames — This is a hack used by web apps to work around browser parallelism limits. For all the reasons that we suggest using a single connection, hostname sharding is suboptimal when you can use SPDY instead. Furthermore, hostname sharding requires extra DNS queries and complicates web apps due to using multiple origins.
С точки зрения событий — возможно, но к каждому соединению как приложение, так и операционная система выделяет некоторым объем памяти.
Так же механизмы хранения коннекшенов, сокетов и отнесение пакета к определенному соединению становится затратнее с ростом числа соединений. Стандартная сборка ядра линукса начинает себя вести плохо начиная с определенного числа соединений, по причине линейного перебора списка в хештаблице.
Так же механизмы хранения коннекшенов, сокетов и отнесение пакета к определенному соединению становится затратнее с ростом числа соединений. Стандартная сборка ядра линукса начинает себя вести плохо начиная с определенного числа соединений, по причине линейного перебора списка в хештаблице.
У Yandex-а слишком хороший сайт, чтобы заметить разницу. На сайтах где не используются подходы с компрессией (склейкой) картинок, css-ок, js-ов и т.д. выйгрыш от внедрения SPDY может быть весьма значительным. И с другой стороны, когда есть возможность хранить мелкие файлы по отдельности, при выходе новых версий, гораздо меньше статического контента браузеру надо будет скачивать заново.
Оверхед TCP хендшейка при скачивании большого файла очень скромен, потому и нет экономии. SPDY даёт ощутимый профит только в ситуации когда страница состоит из массы отдельных файлов — когда CSS/JS не собраны в кучу, когда все графические элементы интерфейса не собраны в один файл, когда на странице 100500 картинок с одного хоста и браузер их ещё и не качает параллельно из-за ограничения 2 коннекта на хост итд итп. Для вылизанного сайта экономится только хендшейк, который в случае разных доменов у разных скачиваемых файлов, для всех файлов всё равно проходит параллельно. Сетевой стек тоже уже оттюнен на большое количество подключений, nginx тоже под это заточен — в общем неоткуда Яндексу ожидать профита собственно ))
А в среднем по больнице SPDY/HTTP2 даст и существенное ускорение и уменьшение количества коннектов. А там глядишь и TCP стек подтянут (стартовый размер окна и деградация при ретрансмите) и вообще будет всё летать ))))
А в среднем по больнице SPDY/HTTP2 даст и существенное ускорение и уменьшение количества коннектов. А там глядишь и TCP стек подтянут (стартовый размер окна и деградация при ретрансмите) и вообще будет всё летать ))))
А можно вопрос про Yandex CDN?
Почему для одинаковых объектов с разных узлов CDN выдается разных Etag?
Пример для файла /browser/update/prtnrs/yandex_s_1700_12508.exe
На узле download.cdn.yandex.net.cache-default05h.cdn.yandex.net Etag — 3737429142
А на узле download.cdn.yandex.net.cache-default03h.cdn.yandex.net Etag — 4275026038
Почему для одинаковых объектов с разных узлов CDN выдается разных Etag?
Пример для файла /browser/update/prtnrs/yandex_s_1700_12508.exe
На узле download.cdn.yandex.net.cache-default05h.cdn.yandex.net Etag — 3737429142
А на узле download.cdn.yandex.net.cache-default03h.cdn.yandex.net Etag — 4275026038
Поправьте пожалуйста в статье ссылку на Navigation Timing API.
Почему проприетарный SPDY, а не свободный HTTP2?
Почему проприетарный? Википедия говорит, что он «an open networking protocol». Более того, SPDY — это не конкурент HTTP 2.0, а его часть.
С чего вы взяли, что SPDY — это часть HTTP2, если HTTP2 — это форк SPDY?
Когда группа HTTPbis решила начать работать над http2, SPDY уже был проверен как рабочая концепция. Он показал, что его возможно развернуть в Интернете, и были опубликованные цифры, которые показывали насколько он справлялся. Работа над http2 впоследствии началась с черновика SPDY/3, который по большому счёту стал черновиком http2 draft-00 после пары операций поиска с заменой.
Хабрапост по этому вопросу
> HTTP2 — это форк SPDY
По-моему, это как раз таки и означает, что SPDY — это часть HTTP 2.0 (т.е. его фичи включены в HTTP 2.0).
По-моему, это как раз таки и означает, что SPDY — это часть HTTP 2.0 (т.е. его фичи включены в HTTP 2.0).
Хм… LibreOffice — форк OpenOffice. Можно ли сказать, что OpenOffice входит в состав LibreOffice?
Или, например, LibreSSL — это сильно усеченный форк OpenSSL. Входит ли OpenSSL в состав LibreSSL, несмотря на то, что LibreSSL не имеет части функционала OpenSSL?
Или, например, LibreSSL — это сильно усеченный форк OpenSSL. Входит ли OpenSSL в состав LibreSSL, несмотря на то, что LibreSSL не имеет части функционала OpenSSL?
Как там было про плохую аналогию и котенка? :)
Сами же пишете «Работа над http2 впоследствии началась с черновика SPDY/3, который по большому счёту стал черновиком http2 draft-00 после пары операций поиска с заменой.».
По вашей аналогии можно сказать так, я думаю — «ранние версии LibreOffice включали в себя части OpenOffice».
Сами же пишете «Работа над http2 впоследствии началась с черновика SPDY/3, который по большому счёту стал черновиком http2 draft-00 после пары операций поиска с заменой.».
По вашей аналогии можно сказать так, я думаю — «ранние версии LibreOffice включали в себя части OpenOffice».
очевидно, потому что он не поддерживается вроде бы нигде. Ну или почти нигде
experiment.yandex.st… meth.yandex.st
Хочется сказать Яндексу — бросайте вы эксперименты с метамфетаминами!
Если у вас много посетителей со старыми Операми (12.*) и используются POST-запросы, мы не рекомендуем вам включать SPDY.Эти оперы не поддерживают SPDY/3.1 и будут работать c nginx 1.5.10+ только по HTTPS, где бага нет. SPDY/2 уже не актуален. А версии nginx до 1.6 на текущий момент уже не поддерживаются и не рекомендованы к использованию в принципе.
Мы все эти эксперименты проводили еще когда еще 1.6 не была стабильной. Поэтому мы будем пробовать :)
В пост внес комментарий.
В пост внес комментарий.
У нас с тех пор ещё блог-пост вышел специально для тех, кто боится ипользовать mainline в продакшене: habrahabr.ru/post/220807/ =)
meth, cocaine, откуда вы только названия берете
Методика не без белых пятен. Как у вас конкретно TLS кэшился и шейкался? Это сильно влияет на количество раундтрипов.
гонщику специально колесо сдули?
Но мы у себя внутри не могли полностью сэмулировать все особенности загрузки почты, все проблемы сети, packet loss и прочие TTL
А что так?
Я для тех случаев, когда в лабе надо контролируемо ухудшить характеристики сети, переключаю клиента в отдельный vrf, трафик из которого в остальной мир проходит через сервер с WANEM. Настроек — мама не горюй. Абсолютно никаких изменений на клиенте не требуется. Неужели Яндекс ничем подобным не пользуется?
Скрытый текст
Можно и через консоль крутить штатный линуксовый tc, но вебморда удобнее.
Можно, конечно, искусственно зарезать канал и увеличивать RTT. И мы это, конечно же, делали. Но всё равно считали, что наших кейсов совсем недостаточно для покрытия всех вариантов. Мы не хотели сделать одним пользователям быстро, за счет того, что у других станет медленно.
Так спору нет, тестировать на ограниченной выборке боевых пользователей в любом случае надо. Но при этом надо организовать лабу так, чтобы она воспроизводила максимально возможное число проблем, тестировать сценарии «из десяти пакетов два приходят не в том порядке», «потери 5%», «джиттер 1000мс при задержке 2000мс, общей полосе 56к и потере 10%» и тому подобное. Это не покроет разве что кейсы «кеширующий прокси провайдера работает коряво на L7».
интересный пост. спасибо.
однако, будет ли команда яндекса тестировать G-WAN? они пишут, что гван работает лучше нгинкса ;)
однако, будет ли команда яндекса тестировать G-WAN? они пишут, что гван работает лучше нгинкса ;)
Спасибо за публикацию интересных результатов! Пару вопросов:
1. Вы пробовали использовать технологию server push? Если нет, то интересно почему.
2. Проводили ли этот же эксперимент для мобильных сетей, где latency последней мили достаточно высокий?
1. Вы пробовали использовать технологию server push? Если нет, то интересно почему.
2. Проводили ли этот же эксперимент для мобильных сетей, где latency последней мили достаточно высокий?
Sign up to leave a comment.
Совместный эксперимент команд Яндекс.Почты и Nginx: действительно ли SPDY ускорит интернет?