Рубрика «asynchronous» - 2

Добрый день, уважаемые читатели ! Данная статья рассчитана на новичков, которые только открывают мир JS, коим являюсь и я. В процессе изучения и проектирования сервера на Node.js разработчик постоянно сталкивается с необходимостью перезагрузки приложения. А в случае, если над проектом работает несколько человек, получаем довольную сложную задачу.

Задача — поднять сервер и обрабатывать несколько url, например http://127.0.0.1/habr и http://127.0.0.1/habrahabr. Сервер должен обрабатывать исключения, а также проект рассчитан на высокую нагрузку.

Цель статьи – разобраться, как создать высоконагруженное приложение, удобное для командной работы и понятное для новичков.
Читать полностью »

Сколько нужно времени, чтобы просто вывести на экран большой список, используя современные фреймворки?

Список на 2000 строк ReactJS AngularJS Raw HTML SAPUI5 $mol
Появление списка 170 ms 420 ms 260 ms 1200 ms 50 ms
Обновление всех его данных 75 ms 75 ms 260 ms 1200 ms 10 ms

Напишем нехитрое приложение — личный список задач. Какие у него будут характеристики?

ToDoMVC ReactJS AngularJS PolymerJS VanillaJS $mol
Размер ( html + js + css + templates ) * gzip 322 KB 326 KB 56 KB 20 KB 23 KB
Время загрузки 1.4 s 1.5 s 1.0 s 1.7 s 0.7 s
Время создания и удаления 100 задач 1.3 s 1.7 s 1.4 s 1.6 s 0.5s

Небольшая головоломка: перед вами синхронный код, загружающий и обрабатывающий содержимое 4 файлов, но с сервера они грузятся параллельно. Как такое может быть?

Синхронная параллельная загрузка ресурсов

А теперь прошу за мной в кроличью нору, настало время удивительных историй...

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

Введение в futures-rs: асинхронщина на Rust [перевод] - 1

Этот документ поможет вам изучить контейнер для языка программирования Rust — futures, который обеспечивает реализацию futures и потоков с нулевой стоимостью. Futures доступны во многих других языках программирования, таких как C++, Java, и Scala, и контейнер futures черпает вдохновение из библиотек этих языков. Однако он отличается эргономичностью, а также придерживается философии абстракций с нулевой стоимостью, присущей Rust, а именно: для создания и композиции futures не требуется выделений памяти, а для Task, управляющего ими, нужна только одна аллокация. Futures должны стать основой асинхронного компонуемого высокопроизводительного ввода/вывода в Rust, и ранние замеры производительности показывают, что простой HTTP сервер, построенный на futures, действительно быстр.

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

Приветствую! В этой статье будет показано, как, имея на руках обычные Future-ы, сделать в scala подобие корутин и асинхронные stream-ы. Этакий небольшой туториал по функциональному программированию.

Что это и зачем

Что такое Future человеческим языком

Future — это сущность, описывающая результат некоторых вычислений, который мы получим не сразу, но в будущем. Но есть одна особенность: зачастую мы, не зная еще результата, точно знаем, что мы с ним будем делать. Например, мы попросили у сервера какой-то конфиг, и теперь у нас есть Future[Config]. Сам конфиг мы еще не получили, но точно знаем, что, когда получим, то достанем из него адрес и по этому адресу попросим у сервера картинку (config => Future[Image]). И Future[Config] способна изменяться таким образом, чтобы мы вместо конфига и потом картинки могли получить сразу картинку. Сущности, способные комбинироваться таким способом, называются монадами.

К сожалению, простое последовательное комбинирование 2х и более асинхронных операций (загрузить конфиг, а потом картинку по адресу из конфига как пример) — это все, на что способны обычные Future-ы в качестве монад. Они не позволяют ни сохранять состояние, ни делать циклы из асинхронных операций, ни выдавать несколько (или бесконечно много) значений. Вот этими недостатками мы сейчас и займемся.

Давайте для определенности представим некий виджет. Он ждет конфиг, который обновляется с определенной периодичностью, загружает по адресу из конфига значение (например, температуру), и рисует на экране текущее значение, минимум, максимум, среднее и так далее. И все это делает в цикле, да еще и асинхронно.

Применив знания из этой статьи, мы сможем этот процесс описать примерно так:

Код

// Про 'FState' - далее, пока же просто примем, что это - такая необычная Future
def getNextConfig: FState[Config]
def getTemperature(from: String): FState[Int]

case class State(temperature: Int, sumTemp: Long, count: Int) {
  def isGood = ...
}

// Как видим, получается единый асинхронный алгоритм с состоянием, 
// которое извне этого алгоритма не видно
val handle = 
  while_ ( _.isGood)
  {  for (
        config <- getNextConfig();
        if (config.isDefined);  // пустой конфиг - прекращаем выполнение
        nextValue <- getTemperature(config().source);  // грузим значение температуры
        state <- gets[State];  // тут мы берем текущее состояние
        newState = State(nextValue, state.sumTemp + nextValue, state.count + 1);
        _ <- puts(newState);  // .. и меняем его
        _ <- runInUiThread { drawOnScreen(newState) }
  ) yield() }

Или вот так:

Код

val configs: AsyncStream[Config] = ... // получаем откуда-то stream конфигов

def getTemperature(from: String): FState[Int]

case class State(temperature: Int, sumTemp: Long, count: Int)

// Получается то же самое, только вместо зависимости 'getNextConfig'
// мы, по сути, передаем сами данные - stream из конфигов
val handle = 
  foreach(configs) {
    config => for (
        nextValue <- getTemperature(config().source);  // грузим значение температуры
        state <- gets[State];  // тут мы берем текущее состояние
        newState = State(nextValue, state.sumTemp + nextValue, state.count + 1);
        _ <- puts(newState);  // .. и меняем его
        _ <- runInUiThread { drawOnScreen(newState) }
    ) yield()  
  }

Всех, кто заинтересовался, прошу под кат.
Читать полностью »

Прошло некоторое время с тех пор, как я писал про Центрифугу в предыдущий раз. Произошло множество изменений за этот период. Многое из того, что было описано в ранних статьях (1, 2) кануло в лету, но суть и идея проекта остались прежними — это сервер рассылки real-time сообщений пользователям, подключенным из веб-браузера. Когда на вашем сайте возникает событие, о котором вам нужно моментально сообщить некоторым вашим пользователям, вы постите это событие в Центрифугу, а она, в свою очередь, отправляет его всем заинтересованным пользователям, подписанным на нужный канал. В самом простом виде это показано на схеме:

Centrifuge — я больше не буду обновлять страницу перед отправкой комментария

Проект написан на Python с использованием асинхронного веб-сервера Tornado. Использовать можно даже если бекенд вашего сайта написан не на Python. Хотелось бы рассказать о том, что Центрифуга представляет собой на данный момент.
Читать полностью »

Привет всем!

В данной статье я хотел бы поделиться с вами соображениями о том, как на практике можно использовать механизм работы с асинхронными процессами, предоставляемый библиотекой jQuery с версии 1.5 под названием deferred, «отложенный» (jQuery.Deferred), а также со связанными объектами и методами.

Разумеется, уже написан не один десяток статей на тему работы с парой deferred/promise. Своей же я задался целью предоставить такой набор знаний, который дал бы новичку, во-первых, возможность забыть о своих страхах перед непонятным и сложным и, во-вторых, сделать еще один шаг к написанию понятного и хорошо структурированного кода, работающего с асинхронными процессами. Я бы хотел сосредоточить свое и ваше внимание на проблемах, которые легко разрешаются ипользованием deferred, на предпосылках и типовых схемах использования этого объекта.
Читать полностью »

Centrifuge — так просто, как возможно, но не проще этого
Привет!

Продолжая статьи о Центрифуге, мне хотелось бы обсудить один из способов подключения реал-тайм событий на сайт.

Суть отдельностоящих серверов рассылки сообщений в реальном времени такова, что клиенты из браузера должны подключиться к серверу, подписаться на нужные каналы и ждать сообщений из этих каналов.
Читать полностью »

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

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

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

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

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

Centrifuge набирает обороты Привет!

Пару месяцев назад я опубликовал на Хабре статью, посвященную описанию open-source проекта Centrifuge. Напомню, что это сервер рассылки сообщений подключенным клиентам (в основном из веб-браузера) в реальном времени. Написан на Python.

С тех пор я продолжал работать над проектом в свободное время и сейчас готов поделиться накопившимися мыслями и изменениями.

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

Доброе время суток! Я занимаюсь разработкой MMORPG. В игре асинхронной загрузкой файлов занимается файловая система встроенная в движок, остальная логика обрабатывалась в основном потоке. Но помимо загрузки файлов есть и другие тяжеловесные операции, например инициализация персонажа, которая включает в себя распарсивание XML данных, композиция текстур и т.д. И я столкнулся с необходимостью разгрузить основной поток игры для повышения fps.
Вооружившись гуглом и прочитав несколько последних статей на Хабре о потоках, решил попробовать свои силы и написать свой велосипед ThreadPool. Основной моей целью было написать простой в использовании и расширяемый пул потоков, с возможностью асинхронного вызова функций с любым количеством аргументов и получения возвращаемого значения. Предлагаемые на Хабре решения меня не устроили в силу многих проблем, от которых я постарался избавиться в своем решении – использовать минимум шаблонной магии и отказаться от абстрактных классов и наследования. Я хочу поделиться своим опытом с вами.

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


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