Компания
315,90
рейтинг
15 мая 2014 в 17:50

Разработка → Совместный эксперимент команд Яндекс.Почты и Nginx: действительно ли SPDY ускорит интернет?

Мы в Яндекс.Почте совместно с командой Nginx провели исследование, чтобы на живом примере с подробностями расставить точки над «ё» в вопросе о том, насколько и за счет чего SPDY ускоряет интернет.

Про сам SPDY вы, конечно, знаете. В 2011 году несколько разработчиков компании Google опубликовали черновик нового протокола, призванного стать заменой привычному HTTP. Его основные отличия заключались в мультиплексировании ответов, сжатии заголовков и приоритизации трафика. Первые несколько версий были не вполне удачными, но к 2012 году спецификация устоялась, появились первые альтернативные (не из Google) реализации, доля поддержки в браузерах достигла 80%, вышла стабильная версия nginx с поддержкий SPDY.



Мы поняли, что, судя по всему, протокол из многообещающей перспективы превращается в хорошее отлаженное решение и начали полноценный цикл работ по внедрению. Начали, естественно, с тестирования. Очень хотелось без него поверить в дифирамбы, опубликованные в блогосфере, но этого в проектах с миллионами пользователей делать нельзя. Мы должны были получить подтверждение, что SPDY действительно даёт ускоряющий эффект.

Есть много интересных исследований вокруг SPDY, в том числе самого Google. Компания-автор протокола показывала, что в их случае SPDY ускоряет загрузку на 40%. Исследование протокола SPDY проводила и компания Opera. Но ни методик подсчета, ни примеров страниц, на которых были достигнуты столь впечатляющие результаты, в этих исследованиях не было.

SPDY. Взгляд изнутри


Протокол SPDY довольно сложный и рассказать о нём непросто. Попробуем наглядно описать, как он работает.

Представим себе веб-страницу, на которой подключены несколько JavaScript- и CSS-файлов. Браузер открывает несколько соединений с сервером и начинает параллельно эти файлы с сервера загружать. Если на сервере включен HTTPS, — а как известно, Яндекс.Почта работает по HTTPS, — для каждого соединения необходимо сделать SSL-handshake, то есть браузеру и серверу нужно обменяться ключами, которыми они будут шифровать передаваемые данные. На это как серверу, так и браузеру необходимо потратить определенное время и ресурсы процессора.

Протокол SPDY призван сократить время — за счет того, что в нем необходимо установить всего одно соединение с сервером, а значит, и handshake необходим всего один. В итоге для загрузки статики браузер устанавливает соединение с сервером и сразу последовательно, не ожидая ответа, отправляет запросы за всеми необходимыми скриптами.



После этого сервер начинает последовательно эти файлы отдавать.

HTTPS

Connect + TLS-handshake Connect + TLS-handshake Connect + TLS-handshake
> GET /bootstrap.css
>…

< HTTP/1.1 200 OK
<…
< body { margin: 0;}
> GET /jquery.min.js
>…

< HTTP/1.1 200 OK
<…
< (function (window, undefined) {
<…
> GET/logo.png
>…

< HTTP/1.1 200 OK
<…
< [data]
<…


HTTPS + SPDY

Connect + TLS-handshake
> GET /bootstrap.css
> GET /jquery.js
> GET /logo.png

< [bootstrap.css content]
<…
< [jquery.js content]
<…
< [logo.png content]


Ускоряем первую загрузку


В нашей почте используется очень много статики. В минимизированном виде в сумме это около 500 мегабайт ресурсов для всех тем оформлений и всех страниц. Это и css и js файлы, и картинки. Из-за большого объема необходимой статики время первой загрузки не молниеносное.

Эту статику мы раздаем пользователям с почти 200 серверов, расположенных в Москве и CDN по всей России и за ее пределами. В качестве сервера мы используем Nginx, так как считаем, что это самый быстрый и надежный из существующих веб-серверов, способных раздавать статику. В прошлом году команда Nginx анонсировала свою реализацию протокола SPDY версии 2 в виде модуля. И мы начали пробовать раздавать статику с помощью Nginx и этого модуля в начале 2013 года.

Текущие оптимизации


Мы давно беспокоимся о скорости загрузки статики. У нас уже много сделано для того, чтобы пользователю нужно было грузить как можно меньше статики. Во-первых, само собой все js-скрипты и css у нас минимизируются при сборке. Мы контролируем размеры картинок и стараемся не выходить за пределы объема статики, необходимой для работы почты.

Во-вторых, у нас применяется технология так называемого фриза статики. Заключается она в следующем: если содержимое файла не поменялось, то у пользователей нет необходимости его перевыкачивать. Поэтому мы делаем так, что его путь от версии к версии остается неизменным. При сборке верстки этот путь получается вычислением хеш-суммы содержимого файла. Например. Для формирования таких путей мы пользуемся Борщиком.

Как мы измеряли время загрузки


Сперва мы решили замерить на своих тестовых машинках, насколько мы ускоримся, просто включив SPDY в конфиге. Мы выложили статику на одну физическую машинку, недоступную для пользователей, которая работала под управлением Ubuntu 12.04. На машинке было 12 ядер и 20GB оперативной памяти. Вся статика помещалась в RAM-диске в оперативной памяти.

Судя по этим замерам, мы ускорили почту очень заметно. Примерно так же, как Google ускорился по их замерам. Но мы у себя внутри не могли полностью сэмулировать все особенности загрузки почты, все проблемы сети, packet loss и прочие TTL. Поэтому, для того чтобы понять, не замедлим ли мы кому-нибудь загрузку, мы решили провести эксперимент на наших пользователях.

Среди них всех случайным образом выбрали 10% и разделили их на две группы: первой группе начали отдавать статику через SPDY, а вторая группа была контрольной.

Для первой группы статика грузилась с домена experiment.yandex.st, а для второй — с meth.yandex.st. Необходимость контрольной группы обуславливалась тем, что у всех пользователей Почты статика могла быть закешированной. Поэтому при их переезде на другой домен им пришлось бы статику перевыкачать, а тем, кто не попал в эксперимент, — нет. Сравнение было бы некорректным.

Метрики


Во всех современных браузерах есть поддержка Navigation Timing API. Это JavaScript-API браузера, который позволяет получать разные данные о времени загрузки. Через него можно с точностью до миллисекунды узнать, когда пользователь перешел на страницу Почты и началась магия с загрузкой статики. Наш клиент-сайд работает таким образом, что он знает момент, когда загружаются все необходимые статические файлы. В наших скриптах мы вычитаем из второго момента первый и получаем время полной загрузки всей статики и отправляем эту цифру на сервер.

Помимо скорости загрузки важным аспектом для нас является количество незагрузок статики. Мы на клиентах проверяем две вещи:

1. Удалось ли вообще получить статический файл. Например, сервер ответил, что такого файла нет. Факт каждой такой незагрузки мы тоже отправляем на сервер и строим график их количества.

2. Пришел ли файл того размера, которого должен был быть. Расскажем об этом типе ошибок подробнее. Мы проверили поведение браузеров в случаях, когда во время передачи файла между сервером и клиентом обрывается соединение. Оказалось, что Firefox, IE и старая Opera передают нам статус 200 и весь недополученный контент. Браузеры не проверяют, что им пришло ровно столько данных, сколько указано в заголовке Content-Length. Но, что еще хуже, IE и Opera при этом кешируют этот недополученный контент, поэтому, пока кеш жив, правильно перевыкачать файл не получится. Firefox, к счастью, при следующем запросе перевыкачивает данные с сервера. Баг, сообщающий об этом неправильном поведении, есть в трекере Mozilla.

Результаты замеров


По полученным цифрам мы посчитали среднее время загрузки статики, медиану, а так же процентиль 80%. Ускорение по нашим приборам, к сожалению, не преодолело статистической погрешности.



Среднее время загрузки уменьшилось на 0.6%. То есть, несмотря на все заверения Гугла, SPDY как таковой не способен взять и ускорить любой сайт на те безумные 40-50%.

Opera 12.16 и Content-Length


Мы попробовали включить SPDY/2 на mail.yandex.ru. После включения у нас появилось много ошибок в логах и нам пришлось его выключить. В Opera есть неприятный баг, который ввиду того, что ее поддержка уже прекращена, вряд ли починится. Заключается он в том, что Opera при отправке POST-запросов отправляет невалидный заголовок Content-Length. Проблема описана здесь: trac.nginx.org/nginx/ticket/337

Если у вас много посетителей со старыми Операми (12.*) и используются POST-запросы, мы не рекомендуем вам включать SPDY.
UPD: Разработчик SPDY подсказывает в комментариях, что в nginx, начиная с версии 1.5.10, уже реализована третья версия протокола, а поэтому старые Оперы уже не будут использовать SPDY при работе с ним. Поэтому и баг Оперы будет неактуален.

Выводы


После наших исследований мы пришли к выводу, что SPDY нам ничего не ускорит, а оптимизация загрузки статики, уменьшение ее размера, оптимальное кеширование оказывают гораздо более — на порядки — заметные эффекты в скорости работы интерфейса.

Однако в SPDY мы нашли для себя неожиданный профит. За счет того, что многие клиенты перестали создавать на каждый файл по соединению, этих соединений стало заметно меньше, а значит, наши процессоры стали меньше нагружаться. То есть какая-никакая, а экономия есть.

Вот как включение SPDY выглядело на графике открытых коннектов на наших серверах.



Разницы в количестве ошибок загрузки статики мы не нашли. Это значит, что включение SPDY в Nginx не создает никаких проблем в браузерах, даже в тех, где он не поддерживается.

Мы провели реверс-инжениринг реализации протокола SPDY в nginx и убедились, что он работает ровно так, как задумано. Еще мы попробовали в тестинге раздавать статику через Apache с подключенным модулем SPDY и померить аналогичным образом на синтетических запросах. Мы убедились, что в этом случае ускорение так же составляло совсем незначительную величину.

В итоге мы включили SPDY на всём yandex.st. Пусть оно нам не принесло ускорения в 100500%, но зато сэкономило некоторое количество электроэнергии за счет меньшей нагрузки на процессор :)

Еще одна причина отсутствия ускорения — Nginx сам по себе является невероятно быстрым сервером. Изначально SPDY было реализовано в виде модуля для сервера Apache, а как известно, ему требуется очень много ресурсов для поддержания соединения. Поэтому экономия коннектов в Apache дает заметный профит в его производительности. В Nginx же на поддержание 10 000 неактивных HTTP keep-alive соединений расходуется около 2.5M памяти (источник — nginx.org/ru).

К сожалению, нам не удалось выяснить, каким образом проводил исследование Google в своих измерениях по ускорению SPDY. Поэтому не следует воспринимать результаты нашего исследования как посыл о том, что этот протокол ничего не ускоряет. Наши выводы — это результат исследования частного случая применения SPDY для раздачи статики.
Автор: @alexeimoisseev
Яндекс
рейтинг 315,90

Комментарии (59)

  • +14
    У вас скорее всего пользователи все из России, и latency весьма небольшой, и доменов немного :). В таком случае, вероятно, действительно будет играть намного бОльшую роль ширина канала, чем что-то ещё.
    • +2
      Пользователи у нас из самых разных мест, но мы стараемся для всех них сохранять как можно меньший latency и развиваем CDN.
      • 0
        За быструю почту и новости — спасибо!
        Надеюсь акселерация трафика Яндекс.Диск в Северной Америке входит в план развития CDN? :)
        А то 20-50 кб\сек — как ножом по сердцу…
    • +2
      Население на большей части территории России получает интернет по спутниковым каналам, поэтому высокий latency и низкая пропускная способность всё еще значимые факторы в нашей стране…
      • 0
        Помимо этого так же не стоит забывать и о мобильном интернете :)
  • 0
    Странный результат (отсутствие ускорения). Имхо, нужно смотреть waterfall диаграмму загрузки контента и сравнивать на разных версиях протокола.
    • 0
      Я думаю у них и так все было очень хорошо оптимизированно, потому и прирост такой незначительный
      • +1
        Оптимизировано для HTTP 1.1. Для SPDY (HTTP 2) рекомендации прямо противоположные, и полностью они не выполнялись, как уже здесь неоднократно отмечено.
        • 0
          Правильно, но кажется, что если все оптимизировать то spdy, то он даст видимый прирост, но быстрее, чем сейчас, не будет
  • +24
    >Однако в SPDY мы нашли для себя неожиданный профит. За счет того, что многие клиенты перестали создавать на каждый файл по соединению, этих соединений стало заметно меньше, а значит, наши процессоры стали меньше нагружаться. То есть какая-никакая, а экономия есть.

    Вот это неожиданность! В протоколе для мультиплексирования нашли мультиплексирование!
    • +8
      Это экономия не за счет мультиплексирования, а за счет меньшего количества файловых дескрипторов для той же нагрузки.
      • –6
        Не понял, а как SPDY может влиять на количество файловых дескрипторов?
        • +3
          соединение > сокет > файловый дескриптор
        • +14
          Вместо четырех http соединений браузер открывает всего-навсего одно.
          Неожиданно потому что у нас nginx использует epoll, а у него асимптотическая сложность O(1) от количества сокетов. Т.е. изменение количества соединений не должно было повлиять на скорость обработки epoll и утилизацию системы. Ан нет;-)
          • +2
            Теперь понял
          • 0
            >Т.е. изменение количества соединений не должно было повлиять на скорость обработки epoll и утилизацию системы.

            а с чего вы решили, что у вас будут потребляться ресурсы именно на epoll?

            большее число fd => больше событий => больше сисколлов => больше контекстсвитчей.
            • 0
              Ну на самом деле в данном случае большее число fd не означает больше событий.
              У нас как был определенный набор статических файлов, так и остался. Как была аудитория из N пользователей так и осталась. Если оценить нагрузку по пропускной способности, т.е. в запросах в секунду, то она какой была такой и осталось. Количество событий в единицу времени тоже должно было остаться тем же. Всем пользователям нужно запрашивать все те же файлы, только по другому протоколу, не по HTTP, а по SPDY, с той же интенсивностью.

              Конечно, в spdy есть мультиплексирование и в сокет может прилететь сразу два запроса, а вычитать мы можем их за один read(). Насколько такая ситуация частая? Мне кажется что она довольно редкая, и такая схема не должна была сэкономить много ресурсов.

              Можно еще сделать буфферизованную запись в spdy-соединение чтобы уменьшить количество вызовов write(), но это опять же очень спорный момент! Станет ли лучше из-за этого? Ведь теперь необходимо задерживать ответ накапливая хоть какой-то буффер.

              Ну и сдается мне декодер/енкодер spdy-протокола несколько сложней аналогичного для http, и должен требовать больше ресурсов.
              • 0
                в принципе, на этот счёт меня сомнения и терзали.
                на свежую голову пришёл более правдоподобный вариант: spdy — бинарный, а http — текстовый.
              • +3
                Все что вы описали, сущая мелочь на фоне того, что происходит в сети.

                Не забывайте, что имея 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.
              • 0
                С точки зрения событий — возможно, но к каждому соединению как приложение, так и операционная система выделяет некоторым объем памяти.
                Так же механизмы хранения коннекшенов, сокетов и отнесение пакета к определенному соединению становится затратнее с ростом числа соединений. Стандартная сборка ядра линукса начинает себя вести плохо начиная с определенного числа соединений, по причине линейного перебора списка в хештаблице.
  • +3
    У Yandex-а слишком хороший сайт, чтобы заметить разницу. На сайтах где не используются подходы с компрессией (склейкой) картинок, css-ок, js-ов и т.д. выйгрыш от внедрения SPDY может быть весьма значительным. И с другой стороны, когда есть возможность хранить мелкие файлы по отдельности, при выходе новых версий, гораздо меньше статического контента браузеру надо будет скачивать заново.
  • +20
    Оверхед TCP хендшейка при скачивании большого файла очень скромен, потому и нет экономии. SPDY даёт ощутимый профит только в ситуации когда страница состоит из массы отдельных файлов — когда CSS/JS не собраны в кучу, когда все графические элементы интерфейса не собраны в один файл, когда на странице 100500 картинок с одного хоста и браузер их ещё и не качает параллельно из-за ограничения 2 коннекта на хост итд итп. Для вылизанного сайта экономится только хендшейк, который в случае разных доменов у разных скачиваемых файлов, для всех файлов всё равно проходит параллельно. Сетевой стек тоже уже оттюнен на большое количество подключений, nginx тоже под это заточен — в общем неоткуда Яндексу ожидать профита собственно ))

    А в среднем по больнице SPDY/HTTP2 даст и существенное ускорение и уменьшение количества коннектов. А там глядишь и TCP стек подтянут (стартовый размер окна и деградация при ретрансмите) и вообще будет всё летать ))))
    • +2
      Более того, SPDY был включён на сервере статики, а не на основном домене. То есть при заходе mail.yandex.ru браузер видит в HTML-коде ссылку на файлы на yandex.st и открывает соединение с ним. Какая разница открывать одно лишнее соединение или шесть параллельных? Всё равно время на этот лишний DNS-запрос и TCP хендшейк потратилось и экономия, на которую рассчитан SPDY, не получена.

      Максимум, тут можно рассчитывать на приоритезацию запросов, но кажется она появилась после 2 версии, и она не ускорит загрузку, она ускорит первоначальный показ страницы после прохода критического пути (получения css-файлов и синхронных скриптов).

      Кроме того, современные браузеры умеют предсказывать будущие запросы за счёт статистики. Если человек часто заходит mail.yandex.ru, браузер уже знает, что потребуются запросы с сервера статики и может заранее открывать соединения.
      • +1
        Дело в том, что у нас не шесть файлов грузится с yandex.st, а несколько десятков. Поэтому рассчитывали сократить количество хендшейков.
        • +6
          Ну, keep-alive же есть.
          • 0
            Постойте, но ведь по SPDY эти несколько десятков файлов параллельно грузится будут, или я что то упустил?
            • 0
              Да, и если какой-то из файлов затупит (не окажется в кеше сервера, например), то он не помешает загрузится другим, потому что не заблокирует соединение.
              • 0
                Благодарю.
  • 0
    А можно вопрос про 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
    • 0
      Разные Etag для одинаковых объектов с разных узлов CDN на одиночного клиента в рамках одиночной сессии конечно не влияют. Но, если оператор доступа в Интернет использует «прозрачные http кеши» то, если не исключать использование Etag в кеш-индексе, то образуются дубликаты объектов.
  • +1
    Поправьте пожалуйста в статье ссылку на Navigation Timing API.
    • 0
      Спасибо, поправили.
  • –9
    Почему проприетарный SPDY, а не свободный HTTP2?
    • +3
      Почему проприетарный? Википедия говорит, что он «an open networking protocol». Более того, SPDY — это не конкурент HTTP 2.0, а его часть.
      • –9
        С чего вы взяли, что SPDY — это часть HTTP2, если HTTP2 — это форк SPDY?

        Когда группа HTTPbis решила начать работать над http2, SPDY уже был проверен как рабочая концепция. Он показал, что его возможно развернуть в Интернете, и были опубликованные цифры, которые показывали насколько он справлялся. Работа над http2 впоследствии началась с черновика SPDY/3, который по большому счёту стал черновиком http2 draft-00 после пары операций поиска с заменой.

        Хабрапост по этому вопросу
        • +2
          > HTTP2 — это форк SPDY

          По-моему, это как раз таки и означает, что SPDY — это часть HTTP 2.0 (т.е. его фичи включены в HTTP 2.0).
          • 0
            Хм… LibreOffice — форк OpenOffice. Можно ли сказать, что OpenOffice входит в состав LibreOffice?

            Или, например, LibreSSL — это сильно усеченный форк OpenSSL. Входит ли OpenSSL в состав LibreSSL, несмотря на то, что LibreSSL не имеет части функционала OpenSSL?
            • +3
              Как там было про плохую аналогию и котенка? :)

              Сами же пишете «Работа над http2 впоследствии началась с черновика SPDY/3, который по большому счёту стал черновиком http2 draft-00 после пары операций поиска с заменой.».

              По вашей аналогии можно сказать так, я думаю — «ранние версии LibreOffice включали в себя части OpenOffice».
    • +4
      очевидно, потому что он не поддерживается вроде бы нигде. Ну или почти нигде
  • –3
    experiment.yandex.st… meth.yandex.st

    Хочется сказать Яндексу — бросайте вы эксперименты с метамфетаминами!
    • +2
      Пусть лучше продолжают: получается хорошо и интересно.
  • +4
    Если у вас много посетителей со старыми Операми (12.*) и используются POST-запросы, мы не рекомендуем вам включать SPDY.
    Эти оперы не поддерживают SPDY/3.1 и будут работать c nginx 1.5.10+ только по HTTPS, где бага нет. SPDY/2 уже не актуален. А версии nginx до 1.6 на текущий момент уже не поддерживаются и не рекомендованы к использованию в принципе.
    • 0
      Мы все эти эксперименты проводили еще когда еще 1.6 не была стабильной. Поэтому мы будем пробовать :)
      В пост внес комментарий.
      • +2
        У нас с тех пор ещё блог-пост вышел специально для тех, кто боится ипользовать mainline в продакшене: habrahabr.ru/post/220807/ =)
  • +9
    meth, cocaine, откуда вы только названия берете
    • +2
      Т-с-с-с, щас Роскомнадзор навлечёте!
  • +2
    Методика не без белых пятен. Как у вас конкретно TLS кэшился и шейкался? Это сильно влияет на количество раундтрипов.
    • +2
      TLS терминировался nginx'ом. Насколько я знаю, использовались различные варианты — с кешированием, TLS тикетами и без.
      Именно потому, что различные браузеры поддерживают различный функционал, использовались случайные выборки пользователей.
  • +3
    гонщику специально колесо сдули?
    • +2
      У гонщика вообще фэйспалм.
      • +1
        Тонкий намёк на неоправданные надежды :)
    • +1
      Посмотрел внимательнее на картинку — да это же спойлер результатов исследования! Сдутое колесо, передний спойлер скребёт по земле, у пилота фейспалм. А так всё хорошо выглядело на первый взгляд!
  • +1
    Но мы у себя внутри не могли полностью сэмулировать все особенности загрузки почты, все проблемы сети, packet loss и прочие TTL

    А что так?
    Я для тех случаев, когда в лабе надо контролируемо ухудшить характеристики сети, переключаю клиента в отдельный vrf, трафик из которого в остальной мир проходит через сервер с WANEM. Настроек — мама не горюй. Абсолютно никаких изменений на клиенте не требуется. Неужели Яндекс ничем подобным не пользуется?
    Скрытый текст
    image

    Можно и через консоль крутить штатный линуксовый tc, но вебморда удобнее.
    • 0
      Можно, конечно, искусственно зарезать канал и увеличивать RTT. И мы это, конечно же, делали. Но всё равно считали, что наших кейсов совсем недостаточно для покрытия всех вариантов. Мы не хотели сделать одним пользователям быстро, за счет того, что у других станет медленно.
      • 0
        Так спору нет, тестировать на ограниченной выборке боевых пользователей в любом случае надо. Но при этом надо организовать лабу так, чтобы она воспроизводила максимально возможное число проблем, тестировать сценарии «из десяти пакетов два приходят не в том порядке», «потери 5%», «джиттер 1000мс при задержке 2000мс, общей полосе 56к и потере 10%» и тому подобное. Это не покроет разве что кейсы «кеширующий прокси провайдера работает коряво на L7».
  • 0
    интересный пост. спасибо.

    однако, будет ли команда яндекса тестировать G-WAN? они пишут, что гван работает лучше нгинкса ;)
    • 0
      думаю, что не раньше, чем G-WAN станет opensource.
  • 0
    Спасибо за публикацию интересных результатов! Пару вопросов:
    1. Вы пробовали использовать технологию server push? Если нет, то интересно почему.
    2. Проводили ли этот же эксперимент для мобильных сетей, где latency последней мили достаточно высокий?
    • 0
      1) В nginx пока нет реализации server push (http://nginx.org/en/docs/http/ngx_http_spdy_module.html)
      2) Мобильные сети мы отдельно не выделяли.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка