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

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

serde — основной фреймворк для сериализации и десериализации в Rust. Его используют как крейт по умолчанию во всей экосистеме. serde_json — это официальный serde-миксин для JSON, так что каждый раз, когда нужно что-то парсить, люди обращаются именно к нему. Конечно, есть и другие библиотеки, специализующиеся на парсинге JSON, например simd-json, но популярность у них, мягко говоря, удручающая. serde_json значительно популярнее: на момент написания от него зависят аж целых 26916 крейта, а от simd-json — всего 66.

Это делает serde_json хорошей мишенью (не как у Jia Tan) для оптимизаций. Велик шанс того, что многим из тысяч пользователей переход на simd-json позволил бы добиться ускорения, но, пока они этого не делают, более мелкие оптимизации — лучше, чем совсем ничего, и такие улучшения — глобальный выигрыш для экосистемы.

Примечание: основная часть изложенного в статье относится к реализации SMT компании Intel, также называемой гипертредингом (hyper-threading). Она основана на научной статье компании, опубликованной в 2002 году.

Привет, Хабр! Сегодня мы поговорим о том, почему BI-платформам нужен движок, какие сложности создает ClickHouse для аналитиков, когда речь действительно заходит о больших данных, зачем нужно оптимизировать SQL и о многих других вещах, которые часто остаются «за горизонтом» в дискуссиях о BI и хранении данных. Говоря другими словами, я хочу рассказать о том, как мы разрабатывали ДанКо — новый движок, который лежит сегодня в основе Visiology 3, а главное — каким образом ДанКо позволяет достичь высокой производительности в аналитических задачах (в некоторых случаях показывая ускорение вплоть до х100)! Эта статья будет полезна тем, кто еще не сталкивался с задачей организации хранения аналитических данных компании, а также интересна тем, кто как раз, наоборот, уже делал это.

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

Очень важно не только писать хороший код, но и использовать все возможности инфраструктуры на максимум. Именно с этой целью в этой статье рассмотрим, как правильно использовать инструменты кэширования внутри Kubernetes и как настроить CDN для максимума производительности Python-приложения.

Самая распространённая конфигурация из мануалов по настройке:
gunicorn --workers 3 wsgi:app

Какое количество воркеров оптимально?
Считается формулой: (Количество ядер процессора)*2+1

А также, у Sync воркеров есть Gthread класс:
gunicorn --workers 5 --threads 2 wsgi:app
Указывая параметр тредов, воркеры автоматически становятся класса Gthread.

В Golang (да в принципе во всех ЯП) управление памятью и эффективное использование ресурсов — основа создания высокопроизводительных приложений. Одним из важных инструментов, который помогает справляться с этой задачей, является сборщик мусора (на англ garbage collection). Встроенный сборщик мусора Go выполняет свою работу довольно хорошо, но иногда требуется более тонкая настройка, чтобы соответствовать специальным требованиям потребностям конкретного приложения.

Здесь нам и помогут кастомные сборщики мусора.

Недавно VMware раскрыла информацию о том, когда наступит end of general support VMware vSphere 7.0, которой сейчас пользуется большая часть рынка. Это произойдет 2 апреля 2025 года. После этой даты для пользователей больше не будет доступных обновлений и патчей продукта, в том числе по информационной безопасности, а поддержка прекратится, когда подойдет к концу срок действия сертификата на нее.

Мы в Orion soft разобрались, что значит конец VMware для российских компаний, с какими последствиями столкнутся те, кто остается на версии 7.0, и что делать, чтобы их избежать.

Многие, наверняка, сталкивались с мемом this is fine, или оригинальным комиксом. Так выглядит типичный день для многих дежурных сотрудников. Оперативные дежурные получают много оповещений, и работа со слишком большим количеством оповещений может привести к усталости от оповещений — чувству истощения, вызванному реагированием на оповещения, которые не имеют приоритета или четких действий. Убедиться в том, что оповещения действенны и точны, а не являются ложными срабатываниями, крайне важно, потому что если дежурные сотрудники постоянно получают ложные уведомления, они могут перестать обращать на них внимание и игнорировать даже важные сообщения. С этой целью в Cloudflare многочисленные команды проводят периодический анализ оповещений, каждая команда разрабатывает свои собственные панели мониторинга для отчетности.

Привет, Хабр! Меня зовут Александр Гавриленко, я занимаюсь интеграциями продуктов в инфраструктурах заказчиков Orion soft. За последние 2 года количество задач, связанных с организацией устойчивой виртуальной инфраструктуры на 2 и более территориально распределенных ЦОДа (со связностью L2), значительно выросло.

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

Отправляем запрос на 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-контроллерами. Нам предстояло провести аудит всей этой красоты и перестроить почти с нуля весь мониторинг с методологией управления ресурсами.