User
Кадр из Top Gear: USA (серия 2)
В своих самых высоконагруженных сервисах мы в Badoo используем язык C и иногда C++. Зачастую эти сервисы хранят в памяти сотни гигабайт данных и обрабатывают сотни тысяч запросов в секунду. И нам важно использовать не только подходящие алгоритмы и структуры данных, но и производительные их реализации.
Практически с самого начала в качестве реализации ассоциативных массивов мы использовали Judy. У неё есть C-интерфейс и множество преимуществ. Мы даже используем обёртку для PHP, так как в версиях PHP до 7.0 Judy сильно выигрывает по количеству потребляемой памяти по сравнению со встроенными мапами.
Однако время идёт, и с момента последнего релиза Judy прошло немало лет – самое время посмотреть на альтернативы.
Меня зовут Марко, я – системный программист Badoo в команде «Платформа». Мы с коллегами провели небольшое исследование в поисках альтернатив Judy, сделали выводы и решили поделиться ими с вами.
Я снимаю кинофестивали, шины от поставщика Формулы-1 и даже робота-хирурга прямо в операционной. Но снимал и из багажника, в студии-каморке, и начинал с подручных средств. Поэтому решил собрать 3 комплекта для съемок под разный бюджет: от бабушкиной пенсии до зарплаты айтишника.
Использовать Guid.NewGuid() в качестве первичного ключа в базе данных — плохая с точки зрения производительности идея. Это связано с тем, что в SQL Server, MySQL и некоторых других БД для первичных ключей создаются кластерные индексы, которые определяют, как строки будут храниться на диске. GUID — это по сути случайное значение, поэтому новая строка может попасть в начало, середину или конец таблицы. Серверу БД в этом случае придётся перемещать другие строки, что приведёт к фрагментации данных, а их извлечение может занять больше времени, если вам нужно извлечь несколько добавленных последовательно записей (например, когда вы добавляете набор связанных сущностей, которые потом будут извлекаться вместе — БД понадобится прочитать данные из разрозненных страниц вместо последовательного чтения набора данных).
Поэтому, чаще всего, лучше пользоваться сгенерированными БД первичными ключами. В SQL Server, например, есть функция NEWSEQUENTIALID(), которая генерирует последовательные GUIDы. Зачем может понадобиться генерировать ключи именно на клиенте и как это правильно сделать?
Cтатья затрагивает тему сериализации данных, которые передаются по unreliable каналам.
В первую очередь это касается реалтайм игр, которые критичны к сетевым задержкам, имеют активное общение клиента и сервера, например, 10 - 60 раз в секунду и используют UDP протокол.
В статье вы узнаете, как с помощью дельта компрессии и квантизации можно уменьшить размер объектов и, тем самым, уменьшить размер сериализованных данных. Попутно мы познакомимся с библиотекой для битовой сериализации данных NetCode.
Привет, Хабр! Я Женя, архитектор интеграционной платформы в Точке, отвечаю за асинхронный обмен сообщениями между внутренними сервисами, за ESB и за брокеры сообщений.
В этой статье я постарался кратко и последовательно изложить основные моменты, о которых полезно помнить при использовании RabbitMQ, если важны стабильность обмена и сохранность данных.
В первую очередь материал рассчитан на разработчиков, которым ещё не приходилось погружаться в тонкости работы с RabbitMQ или использовать его вообще. Более опытным читателям статья может пригодиться в качестве компактной и упорядоченной выжимки из уже знакомых статей, вебинаров и многочисленных страниц документации.
ри разработке игры не всегда есть время на создание отдельных элементов, например, моделей или звуков. Как раз для таких случаев существуют библиотеки ассетов, из которых можно взять нужный контент. Обычно там есть как бесплатные, так и платные ассеты.
Но важно учитывать, что у ассетов есть разные условия использования: например, у одних может вообще не быть ограничений, а у других нужно указывать автора. Поэтому всегда читайте условия, если хотите добавить в свою игру чужие наработки.
Ранее на DTF уже выходили подборки ассетов. К примеру, Арсений Мирный опубликовал список полезных ресурсов для поиска ассетов. Есть подборка от Дмитрия Чикалова, который упомянул не только библиотеки, но и полезные медиа-ресурсы. Иван Михайлов в своём внушительном списке программ для разработчиков также рассказал про библиотеки ассетов.
Наша подборка перекликается с другими списками, но мы выбрали самые удобные ресурсы, в которых легко найти нужные ассеты в условиях ограниченного времени.
Этот материал написан в поддержку нашего инди-джема, в котором ещё можно успеть поучаствовать.
Привет, Хабр! Представляю вашему вниманию перевод статьи Don’t use Lockstep in RTS games.
Lockstep проиграл! Клиент-серверная модель победила и стала стандартом для большинства игр. Стратегии в реальном времени были последними, но в них Lockstep используется все реже и реже. Давайте узнаем почему, но сначала, что такое Lockstep?
Первый игровой автомат Atari Pong, был выпущен в 1972 году. Это игра для двух игроков, основанная на настольном теннисе, где каждый игрок управляет ракеткой и должен отбить мяч на другую сторону. Если игрок промахивается, соперник набирает очки. Первый кто наберет 11 очков становится победителем. Kent Steven в своей книге "The Ultimate History of Video Games" (Вся история видеоигр) описывает, что проект был отдан инженеру Aлану Алькорну (Alan Alcorn), который до этого не занимался играми и игровыми автоматами. Учитывая, что в кармане основателя Atari было немногим больше 500$, и привлечь опытных разработчиков для работы над неизвестным проектом шансы были минимальные, то Нолан Бушелл представил это как выполнение контракта для General Electric.
Алькорн превзошел ожидания на этот проект, кроме функции подсчета очков и таймера раунда, он добавил в игру разделение каждой ракетки на восемь условных сегментов, попадая в которые мяч менял траекторию движения на разные углы. Также вместо проектирования нового аркадного автомата как единого устройства, он использовал дешевый черно-белый телевизор, деревянный шкаф и ручки от газовой плиты. Кроме этого Алан перепроектировал оригинальную схему, заменил компоненты на более дешевые аналоги. Впоследствии таймер раунда был поправлен на изменение скорости шарика, это изменение добавило игре динамики, но потребовало больше памяти, из-за чего игра получила особенность, что ракетки не могли дойти до верхнего края экрана. Алькорну, ограниченному по времени, уже некогда было исправлять такое поведение и баг стал фичей, которая позволяла опытному игроку так отразить мячик, что он улетал в "мертвую зону".
Но каким бы точным и выверенным не был игровой процесс, центром игры является человек, ему свойственно ошибаться. Ошибаться в оценках, в действиях, в движения мышкой или скорости нажатия на кнопки. Когда у игрока не получается выполнить действие, которое, как он думает, было сделано правильно, он начинает ругать игру и окружение, отвлекаться и еще больше ошибаться и бросает играть. Зная эти особенности опытные дизайнеры всегда дают возможность ошибиться, но делают это так чтобы вы этого не заметили. Если игра слишком явно поддается, это раздражает даже больше, чем завышенная сложность.
Давайте разберем к каким уловкам прибегают игры, чтобы играть было интересно.
Целью этой статьи является изучение архитектурного паттерна Entity Component Systems на практике. Я подготовил пошаговое руководство по созданию небольшой игры, с помощью которого вы познакомитесь с основными принципами разработки на Ecs.
В Unity есть класс Gradient, который предоставляет удобные средства для управления градиентом в рантайме и редакторе. Но т.к. это класс, а не структура использовать его через Job system и burst нельзя. Это первая проблема. Вторая проблема — это работа с ключами градиента. Получение значений осуществляется через массив, который создаётся в куче. И как следствие напрягает сборщик мусора.
Сейчас я покажу как можно решить эти проблемы. И в качестве бонуса получить увеличение производительности до 8 раз при выполнении метода Evaluate.
Привет, меня зовут Мария, когда-то я работала на шахте, потом на заводе, а 3.5 года назад пришла в Ozon Tech. Сейчас я старший Golang-разработчик в команде product-facade. Это самый высоконагруженный сервис маркетплейса, но так было не всегда.
Хотите узнать, что скрывается под витриной маркетплейса? Что держит нагрузку в 1 миллион запросов в секунду? Толстые кэши или нечто большее? Про то, как устроено наше кэширование и как мы к этому пришли, — рассказываю в статье.
Сборная солянка из существующих best practices по работе с Grafana и немного с Prometheus, проверенных мной лично. Можно просто положить в закладки — когда-нибудь да пригодится.
