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

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

Первоначально эту нишу занимали крупные инновационные интернет-компании типа 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