Рубрика «latency» - 3

Известный специалист по серверной и клиентской оптимизации, соавтор WebRTC, автор книги "High Perfomance Browser Networking" Илья Григорик из Google опубликовал презентацию “HTTP/2 all the things!”, в которой объясняет, как следует настраивать серверную часть под HTTP 2.0, чтобы повысить скорость загрузки страниц и уменьшить latency, по сравнению с HTTP 1.1.

Илья Григорик о внедрении HTTP 2
Режим Connection View в браузере показывает загрузку элементов заглавной страницы Yahoo.com в HTTP 1.1

Илья начинает с того, что для современных сайтов бóльшая часть задержек приходится на ожидание загрузки ресурсов, при этом полоса пропускания не является ограничивающим фактором (синим цветом на диаграмме Connection View). По статистике, для загрузки средней веб-страницы браузер делает 78 запросов к 12 различным хостам (общий размер загружаемых файлов 1232 КБ).
Читать полностью »

Результаты применения SPDY на сайтах GoogleРовно четыре года назад компания Google анонсировала протокол SPDY, который задумывался как апгрейд для HTTP 1.1 с целью значительно повысить скорость работы всех типов соединений. SPDY позволяет вдвое уменьшить задержку (latency) при работе через HTTP. Делается это за счёт трёх методов: 1) мультиплексирование запросов; 2) расстановка приоритетов для запросов; 3) сжатие заголовков HTTP.

Первые «лабораторные» тесты SPDY показали увеличение скорости загрузки веб-страниц на 55%, в мобильных сетях — на 23%. Впрочем, независимые тесты на реальных сайтах не показали вообще никакой прибавки производительности. Одна из причин — у реальных сайтов ресурсы подгружаются с разных доменов, в том числе с тех, где нет поддержки SPDY.

За прошедшие четыре года многое изменилось. Сам SPDY оптимизирован и вырос до версии 3.1, и его решено сделать основой для протокола следующего поколения HTTP 2.0. Нынешняя реализация поддерживается во всех современных браузерах, в том числе Chrome, Opera, Firefox и даже Internet Explorer, в десятках серверных платформ и на многих крупных сайтах.
Читать полностью »

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

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

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

Однако прогресс не стоит на месте. Архитектура приложений эволюционировала в соответствии с изменившимися требованиями. Приложения, разработанные на основе этой архитектуры, мы называем Реактивными Приложениями. Такая архитектура позволяет программистам создавать событийно-ориентированные, масштабируемые, отказоустойчивые и отзывчивые приложения — приложения, работающие в реальном времени и обеспечивающие хорошее время реакции, основанные на масштабируемом и отказоустойчивом стеке и которые легко развернуть на многоядерных и облачных архитектурах. Эти особенности критически важны для реактивности.

Читать полностью »

Создание многопользовательской realtime игры на node.js

Несколько месяцев назад мы с коллегами решили сделать многопользовательскую realtime игру, которая могла бы работать в вебе. Мы решили использовать node.js для нашего сервера. Это решение привело к очень убедительному успеху — наш сервер работал несколько месяцев без единого падения или перезагрузки процесса.

Мы решили написать нашу игру на node.js, потому что мы слышали много хорошего об этой платформе и очень хотели немного с ней поиграть. И это было потрясающе — мы очень быстро вошли в тему. Для node.js существует множество любопытных библиотек, способных решать абсолютно разные задачи. Побочным преимуществом использования node для серверной части является, собственно, javascript — очень простой в обращении язык. Это позволило нам сфокусироваться на проблемах, которые встречаются во всех realtime играх, без лишней суеты, ограничений и необходимости компилировать код, как это случается при использовании менее динамических языков.

Также node.js проявил себя как очень легковесный язык, даже в моменты пиковой нагрузки. Для нашей игры, процесс node.js использовал только один поток и потреблял всего около 3-4% CPU при одновременной работе 8-10 копий игры, каждая со своим собственным движком обнаружения столкновений.
Читать полностью »

Физик Гарвардского университета Александр Висснер-Гросс (Alexander Wissner-Gross) в интервью Wired высказал мнение, что через 20-30 лет крупнейшие финансовые компании мира начнут использовать ускорители заряженных частиц и нейтринные детекторы, чтобы передавать данные напрямую через Землю. Хотя скорость нейтрино не больше, чем скорость света, но за счёт сокращения маршрута удастся уменьшить latency на несколько десятков миллисекунд.

Опыты по передаче данных с помощью нейтрино уже были. Как раз весной этого года учёные передали информацию с ускорителя в Фермилаб на нейтринный детектор, расположенный в километре от него. Правда, скорость передачи данных во время эксперимента составила всего 0,1 бита в секунду. Но учёные уверены, что с помощью правильной модуляции могут повысить пропускную способность на один-два порядка.
Читать полностью »

«Я могу отправить IP-пакет в Европу быстрее, чем вывести пиксел на экран. Какого хрена?», — спросил Джон Кармак в своём твиттере. Поскольку его твит вызвал широкий резонанс в сообществе, Кармак пояснил, что для замера задержки на наголовном дисплее Sony HMZ-T1 использовал программку, которая меняет содержимое буфера по нажатию клавиши на контроллере, и видеокамеру 240 fps. Затем считал количество кадров между нажатием кнопки и сменой пиксела.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js