Рубрика «performance» - 11

До Java-конференции JPoint 2017 осталось пять недель, 75% докладов уже утверждены, оставшиеся 25% будут выбраны из имеющихся заявок к середине марта. В этом посте я расскажу вам о том, что у нас получилось.

Java-конференция JPoint 2017: Москва, 7-8 апреля — Обзор докладов - 1

Если темы всех докладов разделить по тематикам, то получится следующее:

  • Производительность Java, как на уровне JVM, так и в работе с фреймворками;
  • Препарирование JVM и публичная демонстрация кровавых кишочков;
  • Построение распределенных систем, которые работают;
  • Проблемы параллелизма и многопоточности в больших проектах;
  • Контейнеризация и оркестрация Java-приложений и сервисов.

Плюсом к основным блокам будут доклады на более специфические темы: Kotlin, trueOOP на Java от Егора, паттерны и, конечно, немного паззлеров!

Под катом я расскажу о тех докладах, которые уже утверждены на JPoint 2017. Чтобы все это не выглядело кашей, я попытался разбить доклады по темам.
Читать полностью »

Производительность старта JavaScript - 1

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

В поисках перформанса: мониторинг производительности JVM под Linux при помощи BPF - 1Специалист по низкоуровневой оптимизации приложений, Саша Гольдштейн, в рамках своего доклада на JPoint немного отклонится от привычной тематики .NET и расскажет об инструментарии, помогающем бороться за производительность Java приложений под Linux. Что это за инструмент, кому он нужен и зачем, мы решили узнать заранее и взяли у Саши интервью.

JUG.Ru Group: Расскажите, пожалуйста, пару слов о себе и своей работе?

Саша Гольдштейн: Меня зовут Саша Гольдштейн, последние 10 лет я работаю в израильской консалтинговой компании Sela в качестве CTO.
Моя работа сфокусирована на вопросах оптимизации производительности, диагностике на продакшн, мониторинге и всевозможных низкоуровневых задачах.
Моя типичная рабочая неделя наполнена самыми разными задачами: я преподаю, исправляю ошибки или проблемы производительности для клиентов, а также работаю над внутренними проектами. Также я вхожу в программный комитет пары конференций: нашей собственной SDP (Тель-Авив, Израиль), а также DotNext (Москва и Санкт-Петербург, Россия), что на удивление занимает довольно много времени.

«Производительность большинства приложений определяется не железом или средой исполнения» – Sasha Goldshtein о мониторинге производительности Java под Linux

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

enter image description here

Вы уже используете прогрессивную загрузку? А как насчёт технологий Tree Shaking и разбиения кода в React и Angular? Вы настроили сжатие Brotli или Zopfli, OCSP stapling и HPACK-сжатие? А как у вас обстоят дела с оптимизацией ресурсов и клиентской части, со вложенностью CSS? Не говоря уже о IPv6, HTTP/2 и сервис-воркерах.

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

Drawing Привет! Мы в Badoo стараемся активно участвовать в жизни IT-сообщества: используем многие open-source-технологии и инструменты, а также делимся своими разработками.

Один из таких инструментов – Pinba – сервис для получения realtime-статистики от работающих приложений без накладных расходов на её сбор. Узнать побольше вы можете в этой статье.

Мы стараемся помочь всем, кто использует Pinba в своих проектах и всегда рады слышать success stories, связанные с Pinba. Этот перевод – одна из подобных историй от разработчиков Dailymotion.

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

Создание кастомных Go-профилей с помощью pprof. Запоминаем стеки - 1
Кадр из сериала «Коломбо»

Go-шный пакет pprof часто используется для профилирования процессора или памяти, но не все знают о возможности создавать собственные кастомные профили. Они могут быть полезны для поиска утечек ресурсов или, например, для слежения за злоупотреблением какими-нибудь тяжелыми вызовами.
Читать полностью »

Много ядер не бывает

Атомарные операции (atomics), например, Compare-and-Swap (CAS) или Fetch-and-Add (FAA) широко распространены в параллельном программировании.

Мульти- или многоядерные архитектуры установлены одинаково как в продуктах настольных и серверных компьютеров, так и в крупных центрах обработки данных и суперкомпьютерах. Примеры конструкций включают Intel Xeon Phi с 61 ядрами на чипе, который установлен в Tianhe-2, или AMD Bulldozer с 32 ядрами на узле, развернутых в Cray XE6. Кроме того, количество ядер на кристалле неуклонно растет и процессоры с сотнями ядер, по прогнозам, будут изготовлены в обозримом будущем. Общей чертой всех этих архитектур является растущая сложность подсистем памяти, характеризующаяся несколькими уровнями кэш-памяти с разными политиками включения, различными протоколами когерентности кэш-памяти, а также различными сетевыми топологиями на чипе, соединяющими ядра и кэш-память.
Практически все такие архитектуры обеспечивают атомарные операции, которые имеют многочисленные применения в параллельном коде. Многие из них (например, Test-and-Set) могут быть использованы для реализации блокировок и других механизмов синхронизации. Другие, например, Fetch-and-Add и Compare-and-Swap позволяют строить разные lock-free и wait-free алгоритмы и структуры данных, которые имеют более прочные гарантии прогресса, чем блокировки на основе кода. Несмотря на их важность и повсеместное употребление, выполнение атомарных операций полностью не проанализировано до сих пор. Например, по общему мнению, Compare-and-Swap идет медленнее, чем Fetch-and-Add. Тем не менее, это всего лишь показывает, что семантика Compare-and-Swap вводит понятие «wasted work», в результате – более низкая производительность некоторого кода.Читать полностью »

Этот пост является продолжением поста про оптимизацию производительности списка в React приложении.

Внимание. В данном посте примеры подготовлены специально для Redux приложений. Но сам подход возможно применить и с другими библиотеками. Так же нижеприведенный совет работает в react-redux версии 5. Я не смог достичь желаемого результата в версии 4. Глубоко разбираться в причинах я не стал.

И так, стандартный способ хранить некоторое множество элементов в приложении — это хранить их в массиве:

const state = {
  targets: [{id: 'target1', radius: 10}, {id: 'target2', radius: 2}]
};

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

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

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

Упрощенно задача выглядела так — нужно соединить микроконтроллер с мобильным приложением через интернет. Пример — нажимаем кнопку в приложении зажигается светодиод на микроконтроллере. Тушим светодиод на микроконтроллере и кнопка в приложении соответственно меняет статус.

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

Сразу после запуска вся наша архитектура выглядела так:

12 млрд реквестов в месяц за 120$ на java - 1

Это была 1 виртуалка от Digital Ocean за 80$ в мес (4 CPU, 8 GB RAM, 80 GB SSD). Взяли с запасом. Так как “а вдруг лоад пойдет?”. Тогда мы действительно думали, что, вот, запустимся и тысячи пользователей ринут на нас. Как оказалось — привлечь и заманить пользователей та еще задача и нагрузка на сервер — последнее о чем стоит думать. Из технологий на тот момент была лишь Java 8 и Netty с нашим собственным бинарным протоколом на ssl/tcp сокетах (да да, без БД, spring, hibernate, tomcat, websphere и прочих прелестей кровавого энтерпрайза).

Все пользовательские данные хранились просто в памяти и периодически сбрасывались в файлы:

try (BufferedWriter writer = Files.newBufferedWriter(fileTo, UTF_8)) {
  writer.write(user.toJson());
}

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

В своей домашней лаборатории я использую бесплатную виртуализацию от VMware – это дешево и надежно. Сначала был один сервер, потом в него начал добавлять локальные датасторы, потом собрал второй сервер… Стандартной проблемой при этом был переезд виртуальной машины. Делая эти операции вручную, я наткнулся на один способ, который позволял переключить работающую виртуальную машину на копии флэтов совершенно в другом месте. Способ крайне прост: достаточно создать снапшот виртуальной машины, склонировать флэты в новое место, а затем в дельте перебить ссылку на родительский диск. Гипервизор не держит файлы метаданных диска открытыми, поэтому при удалении снапшота происходит сливание с новым диском, а старый можно спокойно удалять. Этот способ прекрасно работает без всякого VDDK, который недоступен на бесплатных гипервизорах и которым пользуется, например, Veeam в похожей ситуации.

Я без труда автоматизировал эту процедуру на python, применив еще несколько трюков, которые, при наличии запросов, смогу раскрыть в следующих статьях. Немного позже нашелся хороший человек из моих бывших коллег по цеху, который согласился написать гуй, последний, правда, реализован на Unity, но для получившегося бесплатного солюшена, названного нами Extrasphere, это было совсем не плохо. Чем не игрушка для админа?

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


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