Рубрика «высокая производительность» - 55

Оптимизация реляционных баз данных без даунтайма на примере самой нагруженной БД в Badoo - 1

В условиях highload сложность оптимизации реляционных баз данных возрастает на порядок, так как покупка ещё более мощного железа обходится дорого а также уже нет возможности просто выключить приложение ночью для долгого процесса альтера БД и миграции данных.

Недавно мы рассказали, как мы оптимизировали PHP-код нашего приложения. Теперь же пришёл черёд статьи про то, как мы полностью изменили внутреннюю структуру самой нагруженной и важной базы данных в Badoo, не потеряв при этом ни одного запроса.
Читать полностью »

image

Представьте ваш первый день на новой работе. Офис находится в районе совершенно незнакомой вам станции метро Курская. Приближается время обеда. Вы открываете поисковое приложение, пишете «поесть на Курской» и получаете подборку вариантов, где можно отобедать.

Что стоит за запросом «поесть на Курской» и как он обрабатывается, чтобы найти именно то, что нужно вам? В статье я расскажу, как команда Поиска 2ГИС делает всё возможное для того, чтобы жизнь в городах была удобнее и комфортнее для пользователей.
Читать полностью »

Кажется, мы так глубоко погрузились в дебри highload-разработки, что просто не задумываемся о базовых проблемах. Взять, например, шардирование. Чего в нем разбираться, если в настройках базы данных можно написать условно shards = n, и все сделается само. Так-то, он так, но если, вернее когда, что-то пойдет не так, ресурсов начнет по-настоящему не хватать, хотелось бы понимать, в чем причина и как все починить.

Короче, если вы контрибьютили свою альтернативную реализацию хэширования в Cassandra, то вряд ли тут для вас найдутся откровения. Но если нагрузка на ваши сервисы уже прибывает, а системные знания за ней не поспевают, то милости просим. Великий и ужасный Андрей Аксёнов (shodan) в свойственной ему манере расскажет, что шардить плохо, не шардить — тоже плохо, и как это внутри устроено. А еще совершенно случайно одна из частей рассказа про шардинг вообще не совсем про шардинг, а черт знает про что — как объекты на шарды мапить.
Теория шардирования - 1
Фотография котиков (хоть они случайно и оказались щеночками) уже как бы отвечает на вопрос, зачем это всё, но начнем последовательно.
Читать полностью »

То, о чем говорили сторонники Open Source с 1980-х — свершилось! Сегодня архитектура процессоров MIPS стала Open Source. Учитывая, что такие компании как Broadcom, Cavium, китайский ICT и Ingenic платили MIPS за архитектурную лицензию (право сделать совместимую по системе команд микроархитектурную реализацию) миллионы долларов (иногда более десяти миллионов), это историческая веха. Теперь у RISC/V нет преимущества в этом аспекте, да и ARM придется оправдываться. У MIPS до сих пор есть технические преимущества перед RISC/V — лучшая плотность кода у nanoMIPS, лучшая поддержка аппаратной многопоточности, лучшие бенчмарки на high-end ядрах, более полная экосистема. И 8 миллиардов выпущенных чипов на основе MIPS.

Вот команда разработчиков 64-битного процессорного ядра MIPS I6400 «Samurai» и MIPS I6500 «Daimyo» в Сан-Франциско. Это ядро лицензировала в частности японская компания автомобильной электроники DENSO, поставщик Тойоты:

Сегодня MIPS стал Open Source, против RISC-V и ARM. Как Россия повлияла на стратегию американской процессорной компании - 1

А вот представители российской компании ЭЛВИС-НеоТек вместе с русскими, украинскими и казахстанским разработчиком ядер MIPS и софтвера для него. ЭЛВИС-НеоТек является как лицензиатом ядер MIPS, так и разработчиком собственного по микроархитектуре ядра, совместимого с архитектурой MIPS. А также аппаратных блоков видео-обработки и алгоритмов распознавания:

Сегодня MIPS стал Open Source, против RISC-V и ARM. Как Россия повлияла на стратегию американской процессорной компании - 2

Российское MIPS-коммьюнити оказано непосредственное влияние на этот шаг:
Читать полностью »

При разработке продукта редко обращают должное внимание на его производительность при высокой интенсивности входящих запросов. Этим занимаются мало или не занимаются вообще – не хватает времени, специалистов или оправдываются типичной фразой: «У нас на проде и так всё быстро работает, зачем ещё что-то проверять?». В таких случаях может наступить момент, когда прекрасно работающий продакшн внезапно падает из-за нахлынувшего потока посетителей, например, под Хабраэффектом. Тогда становится ясно, что заниматься исследованиями производительности действительно необходимо.

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

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

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

Хороший UX, продуманный дизайн и интуитивный интерфейс — отличные штуки. Но если это всё лагает, пользователи от вас уходят. Иногда разработчики забывают об этом. Темой производительности фронтенда мы с коллегами продолжим серию онлайнов, в которых обсуждаем актуальные вопросы разработки клиентской части.

Прямой эфир, посвящённый перфомансу, пройдёт 18 декабря на ютуб-канале AvitoTech. В дискуссии будут участвовать эксперты из Яндекса, Tinkoff, Mail.Ru и Авито. Под катом — примерные вопросы, которые планируем обсуждать, и ссылка на предстоящую трансляцию. После встречи обновим пост, выложим видео, добавляйте его в закладки, если интересуетесь темой.

Прямой эфир: производительность фронтенда - 1

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

HighLoad Cup #2. Чемпионат для backend-разработчиков снова в строю - 1

Вы готовы к новым нагрузкам? Приглашаем всех любителей и профессионалов на чемпионат по проектированию и администрированию высоконагруженных сервисов HighLoad Cup #2!

Начало соревнованию было положено еще в прошлом году. Тогда мы знали, что HighLoad Cup — это именно тот чемпионат, которого не хватало в ряде проектов Mail.Ru Group. В первом пилотном соревновании участвовало 449 человек. Было много кода и много пота как у самих организаторов, так и участников (8789 различных решений). Были нюансы в технической реализации, но главное, что всем понравилось! Организаторы провели множество ночей в датацентре, несколько выходных — в офисе. Готовы к этому снова! В конце статьи вы найдете полезные материалы от нас и от участников, которые помогут вам разобраться в механике и найти какие-то best practice-решения.

На этот раз постарались подготовить для вас дельце посложнее. Кроме того, мы расширили аудиторию, теперь в соревновании могут принять участие и англоязычные пользователи. Присоединяйтесь к русскоязычному сообществу в Telegram. Там вы получите множество инсайтов по соревнованию :)

HighLoad Cup #2. Чемпионат для backend-разработчиков снова в строю - 2

Итак, добро пожаловать на борт!
Читать полностью »

Если вы занимаетесь выращиванием больших баз данных и вдруг упираетесь в потолок производительности — пришло время расширяться. Со scale-out расширением понятно: серверы добавляете и горя не знаете. Со scale-up все не так весело. Согласно стандартной glueless-архитектуре, мы берем два процессора, потом добавляем к ним еще два… так доходим до восьми и все. Больше Intel не предусмотрел, копите на новый сервер.

Как «склеить» Intel-based сервер и преодолеть scale-up потолок в 8 процессоров - 1

Но есть и альтернатива — glued-архитектура. В ней двухпроцессорные вычислительные блоки соединяются между собой через нод-контроллеры. С их помощью верхний порог на один сервер поднимается до 16 и более процессоров. В этом посте подробней расскажем о glued-архитектуре вообще и о том, как она реализована в наших серверах.
Читать полностью »

Что такое сетевой сервис? Это программа, которая принимает входящие запросы по сети и обрабатывает их, возможно, возвращая ответы.

Есть много аспектов, в которых сетевые сервисы отличаются друг от друга. В этой статье я акцентрирую внимание на способе обработки входящих запросов.

Выбор способа обработки запросов имеет далеко идущие последствия. Как сделать чат-сервис, выдерживающий 100.000 одновременных соединений? Какой подход выбрать для извлечения данных из потока слабоструктурированных файлов? Неправильный выбор приведет к пустой трате сил и времени.

В статье рассмотрены такие подходы как пул процессов/потоков, событийно-ориентированная обработка, half sync/half async паттерн и многие другие. Приводятся многочисленные примеры, рассматриваются плюсы и минусы подходов, их особенности и области применения.

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


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