Вписавшись в очередной провальный заранее стартап, мне прилетела задача: нужны уведомления на сайте. Ладно - сказал я себе. Открываю любимую IDE и начинаю писать очередной микросервис.
До этого я никогда не занимался уведомлениями, но был осведомлен, что есть для этого несколько путей: WebSocket, SSE и Long Polling.
Меня зовут Дмитрий, я специалист по тестированию в студии IT Territory. За 17 лет мы выпустили более 15 успешных игровых проектов с общей аудиторией около 100 млн игроков по всему миру. Вы можете быть знакомы с нами по таким проектам, как Аллоды Онлайн, Hawk, Space Justice, World Above, Rush Royale. И в этом посте я расскажу о том, как мы проводим нагрузочное тестирование игровых серверов.
Оптимизация сетевого кода онлайн-шутера — это не только экономия на серверах и трафике, но еще и создание комфорта для игроков. Она особенно важна, когда на одной карте встречается огромное количество пользователей как, например, в батлрояле на 100 человек.
В этой статье расскажу о том, как мы обновили сетевой код для собственной королевской битвы на Unity, ввели систему сетевых чанков, контролируемый рандом и в результате сократили траты на сервера на 20%.
Мы уже рассказывали, почему первая версия архитектуры игры не была идеальной. Pixel Gun 3D изначально был прототипом в новом для команды жанре PvP-шутер. Хотели протестировать идею, чтобы собрать фидбек от игроков, но популярность игры начала расти достаточно быстро — писать ее заново было уже поздно. Сейчас подход к разработке новых проектов у нас сильно изменился, но зато тогда, без опыта, мы не потратили уйму времени на создание прототипа, который мог оказаться неинтересным для игроков.
С ростом функционала приходилось «на лету» менять архитектуру, делать ее масштабируемой, а также реализовать нашу идею — сделать шутер без даунтаймов даже во время технических работ или форс-мажора.
Далее сравним серверную архитектуру проекта несколько лет назад и сейчас, а также расскажу, как мы добивались дополнительной стабильности с помощью аварийных режимов с рубильниками для серверов.
С июля 2018 Google начали учитывать скорость страниц в выдаче. В ноябре 2019 года они добавили отчет о скорости страниц в личный кабинет Web Search Console. В июне 2021 они ужесточили критерии PageSpeed, подняв влияние Total Blocking Time (TBT) с 25% до 30% и Cumulative Layout Shift (CLS) с 5% до 15%.
Если вы работаете с сайтом, который постепенно растет, - увеличивается количество товаров, трафик с рекламы - то рано или поздно придется перейти в режим работы highload, высоких нагрузок на сервер. Но что делать, если ваш сайт не растет, а сервер все чаще не выдерживает, и происходит блокировка данных? Именно с этой проблемой мы столкнулись, дорабатывая сайт для интернет-магазина светового оборудования с ассортиментом более чем 100 000 товаров.
Сегодня я расскажу вам про довольно простую, но интересную реализацию многопоточности в HTTP-сервере без создания потока для каждого клиента. На мое удивление информацию про такую реализацию я нашёл с трудом, поэтому решил поделиться с вами.
Low-precision inference в TensorRT сегодня - мастхэв, бест практис и прочие иностранные. Сконвертить из TensorFlow легко, запустить легко, использовать fp16 легко. Да и КПД выше, чем у pruning или distillation. На первый взгляд всё работает идеально. Но на самом деле всё ли так гладко? Рассказываем, как мы в TrafficData споткнулись об fp16, встали и написали статью.
Сети доставки контента (CDN) в наши дни получили широкое распространение. Это вполне понятно: растёт число интернет-сервисов с глобальной аудиторией, и почти все такие сервисы так или иначе связаны с доставкой тяжелого (фото-, аудио-, видео- и не только) контента.
Число пользователей Интернета, в особенности — мобильного, растёт с каждым днём, и создатели сайтов и приложений вполне закономерно задумываются об обеспечении быстрой работы в любой точке мира. Спрос рождает предложение — и количество компаний, предлагающих услуги CDN, тоже постоянно растёт. Достаточно набрать в Гугле соответствующий запрос — и в поисковой выдаче будет представлено огромное количество рекламных объявлений.
Как выбрать действительно качественного провайдера CDN? На что обратить внимание в первую очередь?
Где поместить свой сервер, чтобы обеспечить максимальную скорость? Помимо времени, необходимого серверам для ответа на запросы, требуется время просто для доставки пакета из пункта А в пункт Б.
Чтобы теоретически определить лучшее физическое место для размещения своего сервера, я объединил общедоступные данные о задержках с собственными журналами доступа к веб-серверу. Я стремлюсь получить грубый, количественный, ответ, основанный на реальном наборе данных.
Определение TTL для некоторых кэшированных данных («time to live» — время существования или длительность хранения) может стать своего рода шарлатанской нумерологией для программистов. Кеширование по TTL даёт корректность в пользу увеличения скорости. Но до какой степени можно отказаться от корректности? Как долго можно показывать где-то неправильное значение, прежде чем пользователь будет сбит с толку? Как скоро такие пользователи заподозрят наличие у себя проблемы и лягут бременем на службы поддержки клиентов? Давайте разбираться.
