company_banner

Совместный эксперимент команд Яндекс.Почты и 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 для раздачи статики.
    Яндекс 476,72
    Как мы делаем Яндекс
    Поделиться публикацией
    Комментарии 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
                        А можно вопрос про 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) Мобильные сети мы отдельно не выделяли.

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

                                                Самое читаемое