Серверная оптимизация *

Отправляем запрос на 20 000 000 евро, на перестановку 900 ордеров на бирже. Что может пойти не так? 

Сегодня я расскажу, как не терять пару миллиардов клиентских денег, когда уж очень нужно что-то массово сделать на бирже. Этот текст про неявную и, казалось бы, незаметную проблему, которая ждет нас в недрах работы с любыми запросами, которые могут исполниться не до конца – в частности, с HTTP-запросами. Удивительно, как мало об этой проблеме думают и насколько мало инструментов для её решения. 

Задача была такова – реализовать массовое управления биржевыми ордерами, причём не только в рамках одной биржи, а в целом по всей планете. И чтобы оно точно отработало. 

В повествовании будут клиенты, серверы и котики. С котиками всегда интереснее.

Сегодня поговорим о lock-free (или же без использования блокировок) структурах данных и атомарных операциях в Rust.

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

lock-free структуры данных позволяют нескольким потокам одновременно читать и изменять данные без блокировок.

Часть 1

В этой части я приведу ещё несколько примеров того, как нам мешает скачивание обновлений внутри приложений.

Пример 1: обновления macOS

Ни для кого не секрет, что обновления macOS огромны. Иногда это раздражает даже дома, но на Южном полюсе ситуация гораздо хуже.

Размер патча минорного обновления macOS обычно имеет размер от 0,5 до 1,5 гигабайтов. Патчи с крупными обновлениями иногда занимают до шести с лишним гигабайтов. Дополнительные инструменты, например Xcode, часто весят несколько гигабайтов.

Хеширование – это мощный инструмент, широко используемый в различных областях IT: от защиты паролей до создания быстрых структур данных. В этой статье мы подробно рассмотрим, как хеширование помогает оптимизировать хранение данных, исключить дубликаты и улучшить работу с файлами.

Привет, Хабр! Меня зовут Кирилл, и я — архитектор инженерных систем в «Инфосистемы Джет». «При чем тут машинное обучение?» — спросите вы. Действительно, применимость ML к инженерной инфраструктуре — направление более чем свежее, и на Хабре еще никто эту тему не поднимал (кажется!).

Но сначала я расскажу предысторию. Инженерная инфраструктура в большинстве случаев является критически важной для функционирования дата‑центра. Ее безотказная работа — основной критерий при разработке проекта будущего ЦОД. Повышение энергоэффективности и надежности эксплуатации — не менее важная проблема, будоражащая умы инженеров на протяжении последних лет.

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

Часть этого поста я написал, всё ещё находясь в Антарктиде, но уеду, ещё не закончив его.

Я просматривал свои старые черновики постов и понял, что этот почти завершён.

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

В течение 14 месяцев работы в Антарктиде доступ в Интернет у меня был только через крайне ограниченное число спутниковых каналов, предоставленных Антарктической программой США (United States Antarctic Program).

В начале поста нужно дать особое примечание:

Хотя я был ИТ-сотрудником United States Antarctic Program, всё, о чём я буду говорить в этом посте, основано или на публично доступной информации, или на моих личных наблюдениях как обычного участника программы, живущего во льдах.

При написании поста не использовалась информация с ограниченным доступом и непубличная информация.

При приёме на работу я подписал условия, ограничивающие публичное раскрытие непубличной информации о материалах, связанных с информационными технологиями. Я намерен полностью соблюдать эти ограничения. Такие ограничения типичны для сдельной работы на правительство США.

Маловероятно, что я смогу ответить на дополнительные вопросы по темам, обсуждаемым в этом посте. Я тщательно старался писать максимально подробно, не допуская при этом раскрытия непубличной информации о правительственных ИТ-системах.

Данная информация отражает мой личный опыт нахождения в Антарктиде с августа 2022 года по декабрь 2022 года в Мак-Мердо, а затем с декабря 2022 года по ноябрь 2023 года на Южном полюсе.

Привет, Хабр!

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

Как и наши хвостатые друзья, существует такой паттерн как Lazy Loading, который позволяет экономить ресурсы, инициализируя объекты только тогда, когда они действительно нужны.

Рассмотрим, как мы можем применить этот котиковый подход в Java. Будем как котики — умными, экономными и эффективными!

Вы, конечно, знаете, что сервер является сердцем любого онлайн-сервиса или офисной сети. Именно серверы обеспечивают работоспособность наших любимых веб-сайтов, приложений, игр и социальных сетей, а нам позволяют открывать их 24 часа в сутки 7 дней в неделю. Эта статья — для новичков, которые не задумывались, чем отличаются серверы друг от друга, какими они бывают, а также коснемся вопроса выбора сервера.

Дисклеймер: это вводный материал в серии, посвященной серверам. Тут мы разберем основные понятия. А для тех, кто с серверами "на ты", совсем скоро выйдут материалы, в которых мы более глубоко разберем различные аспекты, касающиеся серверов, с профессиональной точки зрения.

К нам обратился заказчик из сфера развлекательного видеостриминга с интересной проблемой - у него сервера падали не одновременно. А очень хотелось бы добиться синхронности.

Сервера, которые смущали заказчика работали в роли бэкенда для хранения видеофайлов. По сути, это было множество узлов, содержащих десятки терабайт видеофайлов, которые предварительно были нарезаны в разном разрешении конвертерами. Затем, все эти миллионы файлов отдавались во внешний мир с помощью nginx + kaltura, что позволяло перепаковывать на лету mp4 в сегменты DASH/HLS. Это позволяло хорошо переносить даже высокие нагрузки, отдавая плеером только нужные сегменты без резких всплесков.

Проблемы появились тогда, когда встал вопрос с георезервированием и масштабированием при росте нагрузок. Сервера внутри одной группы резервирования умирали не синхронно, так как представляли были весьма разнообразным зоопарком с разными провайдерами, шириной канала, дисками и RAID-контроллерами. Нам предстояло провести аудит всей этой красоты и перестроить почти с нуля весь мониторинг с методологией управления ресурсами.

При работе с современными веб-приложениями реального времени незаменима возможность отправлять события с сервера на клиент. Именно этой необходимостью продиктовано то, что за годы работы было изобретено несколько методов для этой цели, каждый с собственным набором достоинств и недостатков. Первоначально единственным вариантом был длинный опрос. Затем в качестве альтернативы появились веб-сокеты — более надёжное решение для двунаправленной коммуникации. Вслед за веб-сокетами появились события, отправляемые сервером (SSE), более простой метод, обеспечивающий однонаправленную связь от сервера к клиенту. Забегая вперёд, сейчас разрабатывается ещё и протокол WebTransport, который может тем более изменить ландшафт этой области, обеспечивая более эффективный и гибкий подход, располагающий к масштабированию. В некоторых нишевых случаях можно присмотреться и к технологии WebRTC, предназначенной для работы с событиями в направлении сервер-клиент.

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

Привет, друзья! С этой статьи компания Orion soft начинает вести свой блог на Хабре. Сегодня я расскажу о том, как происходит развертывание системы виртуализации zVirt. Текст предназначен для тех, кто еще ни разу не работал с нашим гипервизором, но в тайне (или явно) мечтает об этом. Мы с коллегами решили помочь вам сэкономить свое время, познакомившись с процессом деплоя виртуально, и подготовили инструкцию how-to (можно повторять все прямо за нами). Под катом — подробный гайд по развертыванию zVirt в режиме Hosted Engine (то есть прямо на ваших хостах) с примерами значений, рекомендациями по базовым настройкам и понятными скриншотами. Так что если вы ждали знак, чтобы решиться установить у себя zVirt, вот он. Время пришло сегодня :)

Привет, Хабр!

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

Традиционный подход к оптимизации гиперпараметров включает в себя grid search и random search, иногда они могут быть неэффективными и времязатратными, особенно когда пространство гиперпараметров велико.

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

Optuna решает проблему оптимизации гиперпараметров, предоставляя легковесный фреймворк для автоматизации поиска оптимальных гиперпараметров. Она использует алгоритмы, такие как TPE, CMA-ES, и даже поддерживает пользовательские алгоритмы.

Optuna полностью написана на Python и имеет мало зависимостей. В этой статье рассмотрим её основной функционал.

Может ли быть так, что в большинстве популярных языков отсутствует самый эффективный механизм синхронизации? Что инженеры Microsoft, Oracle и мн. др., не говоря уже об остальных, вплоть до 2024 года так и не догадались, как же эффективнее всего синхронизировать доступ к данным? А все что знает абсолютное большинство программистов, в том числе топовых IT компаний (за исключением редких разработчиков платформ Apple) о синхронизации — ошибочно? Сегодня попробуем разобраться.

Эта статья подразумевает, что вы уже имеете базовое представление о механизмах синхронизации. Код написан на C#, но конкретный язык особого значения не имеет.

Погружение в мир контейнеризации с докером — это путь к оптимизации развёртыванию приложений, а также ключ к упрощению жизни разработчиков и системных администраторов. Меня зовут Андрей Аверков, в IT c 2008 начинал пусть с аналитика-проектировщика IT систем, 11 лет в роли разработчика и последние годы на руководящих должностях. Сейчас я тимлид команды разработки из 9 человек в группе компании Кокос. Мы занимаемся созданием и поддержкой CPA платформ (gdeslon.ru, fxpartners.ru, ads.mobisharks.com), а также проектом по генерации лендингов — lpgenerator.ru. У нас большой опыт в разделении продуктов на части, поэтому, сегодня мы собрали самое основное и необходимое для работы с Docker. В нашей шпаргалке вы найдете все необходимое для успешного старта с докером: от базовых концепций и установки до продвинутых техник работы с контейнерами.

Привет, Хабр!

Traefik - современный и мощный балансировщик нагрузки.

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

Хабр, привет! На связи Алексей Зотов из К2Тех, и сегодня я хочу поговорить об одном из российских решений для виртуализации. Сегмент этот в каком-то смысле уникален. Если в целом по рынку заказчик выбирает между 5–6 отечественными продуктами для решения задачи импортозамещения (например, это ярко видно на примере СРК или служб каталога). То в сегменте виртуализации мы насчитали уже более трех десятков конкурирующих платформ!

В предыдущих статьях про тестирование серверов Inferit и Аквариус, а также про создание суперкомпьютера я упоминал платформу zVirt. Мы с этим продуктом работаем уже довольно давно, неплохо его изучили и можем оценить его развитие. Тем более, вендор Orion soft позиционирует zVirt как конкурентную альтернативу VMware. Пора проверить это заявление. 

Я решил испытать этот продукт и протестировать новые фичи, которые появились в zVirt 4.1: Disaster Recovery (DR), V2V-миграция из VMware, управление сетями SDN. Результаты тестирования и впечатления от платформы – под катом.