Называть статью «Эволюция прикладных информационных систем и перспективы развития их архитектуры» было бы слишком академично, а ведь тут будет очень краткая выжимка из реального практического опыта, возможные варианты развития технологий, вызвавшие их потребности и пути решения. Я надеюсь, что статья поможет обобщить и переосмыслить широкий круг задач, связанных с прикладными ИС, и сразу хочу уточнить, что понимаю под этими терминами. ИС — это системы, обеспечивающие обработку, передачу и хранение данных. Это далеко не все программирование, но сейчас ИС чаще всего ассоциируются с веб и мобильными приложениями, хотя и не совпадают с ними полностью, знак равенства между UI и ИС нельзя ставить тем более. Очень прошу всех посмотреть на вопрос как можно шире и присоединяться к обсуждению в комментариях. И еще, я намеренно не буду использовать названия фреймворков и технологий, чтобы избежать лишних холиваров, ограничившись общепринятыми названиями архитектур, стандартов и протоколов, что и вам рекомендую в комментариях.
Читать полностью »
Рубрика «высокая производительность» - 97
Эволюция приложений или куда мы идем
2017-04-12 в 0:16, admin, рубрики: api, RPC, Анализ и проектирование систем, архитектура, браузер, браузеры, ветхий веб, высокая производительность, интернет, исследование, клиент, обзор, прогноз, Программирование, протокол, Разработка веб-сайтов, реактивность, сервер, СУБДTarantool как основное хранилище данных для серверных приложений, написанных на .NET
2017-04-11 в 12:57, admin, рубрики: .net, .net core, mail.ru, open source, tarantool, Анализ и проектирование систем, Блог компании Mail.Ru Group, высокая производительность
Этот пост — текстовая версия доклада, представленного на Tarantool Meetup второго марта 2017-го года в Mail.Ru Group с поправкой на то, что прошёл уже месяц, и кое-что из обещанного уже было реализовано, поэтому текст будет интересен даже тем, кто видел выступление.
Большое спасибо коллегам, друзьям и сотрудникам компании Mail.Ru Group, которые помогали написать эту статью.
Выбор СУБД
В жизни каждого проекта рано или поздно возникает переломный момент, когда нужно выбрать СУБД для хранения всех данных. Наш проект с этой точки зрения простой: пользователи, голосования, ответы, какая-то попутно собираемая информация — всё это прекрасно можно держать в key-value хранилище. Поэтому на старте мы рассматривали три варианта: Redis, Tarantool и MySQL с handlersocket. Фаворитом с самого начала был Redis. Он быстро работает, у него замечательный коннектор для .NET, созданный командой Stack Overflow. К слову, сам Stack Overflow написан на .NET, работает на Windows, у них SQL Server от Microsoft, Redis и ещё много интересного. У Redis прекрасная документация. Если мы нанимаем нового программиста, который никогда не работал с Redis, то мы отправляем его туда — и через три дня он знает примерно всё, что ему нужно знать для использования Redis.
Бесплатная трансляция главного трека JPoint 2017. Сейчас! Без регистрации и смс
2017-04-08 в 5:51, admin, рубрики: java, jpoint, Блог компании JUG.ru Group, высокая производительность, доклады, конференция, трансляцияВсем привет! В прошлом году на Joker 2016 мы делали открытую трансляцию главного зала. В тот раз не обошлось без технических заминок, но в целом зашло хорошо. Мы решили продолжать славную традицию и сделать это еще раз – сегодня с 10 утра мы начинаем бесплатную YouTube-трансляцию первого трека JPoint 2017! Первый трек – самый большой и хардкорный, будут доклады Алексея Шипилёва, Евгения EvgenyBorisov Борисова, Arun Gupta, Сергея Walrus Куксенко и не только
Если кто не в курсе, вчера успешно прошел первый день международной Java-конференции JPoint 2017: 1200 участников, 25 докладчиков, 20 докладов, 4 трека, – все серьезно. Но пост будет не о прошедшей конференции, а о том, что нам (и некоторым из вас) еще предстоит.
Под катом – список докладов и ссылка на YouTube.
Читать полностью »
Как сократить время запуска приложений под iOS
2017-04-07 в 7:21, admin, рубрики: iOS, Блог компании JUG.ru Group, высокая производительность, мобильное приложение, разработка мобильных приложений, разработка под iOSМобильные процессоры и память все быстрее, а приложения загружаются все так же. В чем соль? Вопрос времени запуска iOS-приложений занимает ум не одного разработчика (особенно после перехода на Swift). Мы решили выяснить причины долгой загрузки и варианты решения этой проблемы у Николая Лихогруда, разработчика Мобильных Яндекс.Карт.
Под катом: типичные грабли, полезные инструменты и правильные подходы к решению проблем с производительностью.
Читать полностью »
Кинетика больших кластеров
2017-04-06 в 9:40, admin, рубрики: big data, Алгоритмы, Анализ и проектирование систем, высокая производительность, кинетика, Промышленное программирование, распределенные системы, репликация, метки: кинетикаКраткое содержание
- Фатальная ошибка Мартина Клеппмана.
- Физико-химическая кинетика уделывает математику.
- Период полураспада кластера.
- Решаем нелинейные дифференциальные уравнения, не решая их.
- Ноды как катализатор.
- Предсказательная сила графиков.
- 100 миллионов лет.
- Синергия.
В предыдущей заметке мы подробно разбирали статью Брюера и его одноименную теорему. На этот раз займемся препарированием поста Мартина Клеппмана «The probability of data loss in large clusters».
В данном посте автор пытается промоделировать следующую задачу. Для обеспечения сохранности данных обычно используется метод репликации данных. При этом, на самом деле, не важно, используется ли erasure кодирование или нет. В оригинальном посте автор задает вероятность выпадения одной ноды, а затем ставит вопрос: а какова вероятность выпадения данных при увеличении числа нод?
Ответ приведен на этой картинке:
Читать полностью »
TCP и UDP сервера с использованием Netty 4
2017-04-06 в 1:00, admin, рубрики: java, Анализ и проектирование систем, высокая производительность, Программирование, метки: java, netty, programming, server-side, tcp, udp, unixЯвляясь Unity разработчиком, я со временем дошёл до того этапа, когда возникла необходимость написания сервера. Передо мной стояло много неизведанных троп сетевого программирования, в котором я потом повяз по голову. Прыгал между C++, C# и Java. После долгий скитаний я нашёл то, чему я сейчас говорю спасибо. Об этом я и хочу поведать.
Читать полностью »
Отказоустойчивая обработка 10M OAuth-токенов на Tarantool
2017-04-05 в 10:50, admin, рубрики: Lua, mail.ru, perl, raft, tarantool, Анализ и проектирование систем, Блог компании Mail.Ru Group, высокая производительность
Многие уже наслышаны о производительности СУБД Tarantool, её возможностях и особенностях. Например, у него есть классное дисковое хранилище — Vinyl, кроме того, он умеет работать с JSON-документами. Но в многочисленных публикациях обходят стороной одну важную особенность. Обычно БД рассматривают просто как хранилище, но всё же отличительная черта Tarantool — это возможность писать код внутри и очень эффективно работать с этими данными. Под катом рассказ, как мы строили одну систему почти полностью внутри Tarantool, написанный в соавторстве с Игорем igorcoding Латкиным.
Библиотека Google Benchmark
2017-04-05 в 10:12, admin, рубрики: benchmark, c++, google benchmark library, microbenchmarks, wunder fund, wunderfund, Блог компании Wunder Fund, высокая производительность, Программирование, метки: google benchmark library, microbenchmarks
Не так давно я писал о C++ библиотеках для микробенчмаркинга. Я рассказал о трех библиотеках: Nonius, Hayai и Celero. Но в действительности я хотел поговорить о четвертой. Мой Windows тогда не поддерживал Google Benchmark library, так что я не мог ее протестировать. К счастью, из комментариев к прошлому посту я узнал, что теперь библиотека доступна в Visual Studio!
Давайте посмотрим, как можно ее использовать.
Читать полностью »
Простейший HTTP сервер на Golang и Elixir. Сравнение производительности
2017-03-31 в 7:00, admin, рубрики: ab, Erlang/OTP, Go, golang, jmeter, wrk, Анализ и проектирование систем, высокая производительность, Тестирование веб-сервисов
Пару недель назад, я решил взять простейший пример HTTP сервера на Go и измерить его производительность. Потом я смело взял Phoenix, прогнал на тех же тестах, и расстроился. Результаты были не в пользу Elixir/Erlang (45133 RPS у Go и всего 3065 RPS у Phoenix). Но Phoenix — это тяжело. Надо что-то хотя бы примерно равное по простоте и логике разработки тому, что есть на Go: когда есть путь — "/" и handler для него. Логичной аналогией мне показалось решение cowboy + plug, где у нас есть Router, который так же ловит "/" и отвечает на него. Результаты убили — Elixir/Erlang опять оказался медленнее:
Golang
sea@sea:~/go$ wrk -t10 -c100 -d10s http://127.0.0.1:4000/
...
452793 requests in 10.03s, 58.30MB read
Requests/sec: 45133.28
Transfer/sec: 5.81MBelixir cowboy plug
sea@sea:~/http_test$ wrk -t10 -c100 -d10s http://127.0.0.1:4000/
...
184703 requests in 10.02s, 28.57MB read
Requests/sec: 18441.79
Transfer/sec: 2.85MBКак жить дальше? Две недели я не спал и не ел (почти). Все, во что я верил все эти годы: совершенство vm erlang, ФП, зеленые процессы, было растоптано разорвано, сожжено и пущено по ветру. Немного отойдя от шока, успокоившись, и подтерев сопли я решил разобаться, в чем дело.
Инфраструктура Twitter: масштаб
2017-03-30 в 13:03, admin, рубрики: BGP, Blobstore, cassandra, Clos, FlockDB, Gizzard, graph, Hadoop, Haplo, Manhattan, memcache, mesos, MPLS, mysql, Nighthawk, puppet, redis, RSVP, Snowflake, twitter, twitter api, высокая производительность, инфраструктура, Проектирование и рефакторинг, Системы обмена сообщениямиОбзор парка Twitter
Twitter пришёл из эпохи, когда в дата-центрах было принято устанавливать оборудование от специализированных производителей. С тех пор мы непрерывно разрабатывали и обновляли серверный парк, стремясь извлечь пользу из последних открытых технологических стандартов, а также повысить эффективность работы оборудования, чтобы обеспечить наилучший опыт для пользователей.
Наше текущее распределение оборудования показано ниже:
