Распределенные системы в Одноклассниках / Олег Анастасьев (Одноклассники)Ontico
«Одноклассники» состоят из тысяч серверов, большая часть которых участвует в онлайн-обработке запросов пользователей. Каждый из этих серверов владеет только частью данных или логики. Эти части в социальной сети изолировать друг от друга невозможно, поэтому между серверами происходит много сетевого взаимодействия — разнообразного и большого по объему. Таким образом, Одноклассники — это одна из самых больших, сложных и нагруженных распределенных систем в мире.
В этом докладе Олег расскажет об опыте построения отказоустойчивых распределенных систем на Java, основных ошибках и отказах, приемах их тестирования и диагностики. Также речь пойдет об авариях в распределенных системах и методах их предупреждения.
Автоматизация тестирования клиентской производительности / Николай Лавлинский...Ontico
Клиентская производительность – бесконечный процесс. Разрабатываются новые фичи, меняется дизайн, технологии, браузеры – контролировать скорость нужно постоянно.
В этих условиях требуется автоматизированный процесс тестирования скорости клиентской части приложения. При этом тестировать нужно в настоящих браузерах, в максимально похожем на реальность окружении.
В этом докладе будем говорить о том, как совместить все эти требования и не потратить много месяцев на построение собственного "велосипеда". Предлагается рабочее решение задачи с использованием open source решения WebPagetest Private Instance. Рассмотрим основные достоинства и проблемы решения, а также способы использования этого инструмента.
Как сделать ваш JavaScript быстрее / Роман Дворнов (Авито)Ontico
JavaScript, который мы пишем, не всегда исполняется, как мы думаем. Виртуальные машины, исполняющие его, делают многое, чтобы он работал быстрее. Но они не всесильны, и чтобы сделать код действительно быстрым, нужно знать их особенности и как все работает под капотом.
Поговорим об этих особенностях, что может служить причиной потери производительности, как это диагностировать и как делать код действительно быстрым. Доклад базируется на опыте, полученном в ходе работы над такими проектами как basis.js (весьма быстрый фреймворк для SPA), CSSO (минификатор CSS, который из медленного стал один из самых быстрых), CSSTree (самый быстрый детальный CSS парсер) и других.
Artisto: опыт запуска нейросетей в production / Эдуард Тянтов (Mail.ru Group)Ontico
Artisto - первое в мире мобильное приложение для обработки видео с помощью нейросетей в стиле картин художников и любых исходных изображений. Приложение вошло в топы AppStore и Google Play в США.
В рамках доклада расскажу:
- как научить нейросети рисовать, а, главное, красиво и быстро;
- про особенности переноса стиля на видео;
- про технологический стек.
Жизнь проекта на production советы по эксплуатации / Николай Сивко (okmeter.io)Ontico
Ваш сайт или другой проект приносит деньги только тогда, когда он работает.
Нельзя просто выложить код на серверы, залить схему в базу данных и делегировать домен.
Будем говорить о планировании отказоустойчивости и мониторинге проектов:
- оцениваем риски отказа различных компонентов;
- какие-то из вероятных проблем просто мониторим и планируем действия при сбоях;
- проблемы, которых можно избежать легко и дешево, закрываем сразу.
Расскажу на примерах о том, что всё всегда ломается, но с этим можно жить.
noBackend, или Как выжить в эпоху толстеющих клиентов / Самохвалов НиколайOntico
Набирает обороты мода на парадигму noBackend (см., например, http://nobackend.org/). Название не стоит понимать буквально: backend никуда не делся, просто фокус разработки — особенно на начальном этапе развития нового проекта — сильно смещается в сторону «клиентской части». Это очень понятно и закономерно в эпоху Mobile First и React Ecosystem с её новомодными GraphQL и React Native.
Появляется большой соблазн взять что-то понятное для хранения данных и уже «обвязанное» REST API, максимально отказаться от PHP/Python/Ruby/Java/etc, писать 80% кода «на стороне клиента», минимально заботясь о возне «на стороне сервера». У некоторых возникает и настоящая эйфория — чувство приятное, но очень опасное (прежде всего, если в команде нет сильного backend-опыта).
Этот доклад — компиляция опыта ряда проектов, написанных на React, React Native и Swift и переходящих на парадигму (или же сразу стартанувших с неё) noBackend за счёт PostgreSQL+PostgREST.
Мы обсудим важные вопросы, которые обязан задавать себе каждый, выбравший noBackend-подход (и не обязательно на связке Postgres+PostgREST): безопасность (аутентификация/авторизация; ограничение чтения и — особенно! — модификации «чужих» данных), производительность (нетривиальные запросы а-ля «свежий контент от тех, на кого я подписан»; компромисс между сетевой сложностью и CPU; защита от «домашнего» ddos — ситуации, когда свои же, родные «фронтендеры» кладут «бэкэнд»), масштабируемость и асинхронная обработка задач.
Задача-минимум (для всех): у каждого слушателя остаётся список must-check-вопросов для работы с noBackend-подходом.
Задача-максимум (для тех, кто с Postgres-опытом): разворачивание безопасного, высокопроизводительного и годного для быстрого развития REST API — сегодня же, в день док
Распределенные системы в Одноклассниках / Олег Анастасьев (Одноклассники)Ontico
«Одноклассники» состоят из тысяч серверов, большая часть которых участвует в онлайн-обработке запросов пользователей. Каждый из этих серверов владеет только частью данных или логики. Эти части в социальной сети изолировать друг от друга невозможно, поэтому между серверами происходит много сетевого взаимодействия — разнообразного и большого по объему. Таким образом, Одноклассники — это одна из самых больших, сложных и нагруженных распределенных систем в мире.
В этом докладе Олег расскажет об опыте построения отказоустойчивых распределенных систем на Java, основных ошибках и отказах, приемах их тестирования и диагностики. Также речь пойдет об авариях в распределенных системах и методах их предупреждения.
Автоматизация тестирования клиентской производительности / Николай Лавлинский...Ontico
Клиентская производительность – бесконечный процесс. Разрабатываются новые фичи, меняется дизайн, технологии, браузеры – контролировать скорость нужно постоянно.
В этих условиях требуется автоматизированный процесс тестирования скорости клиентской части приложения. При этом тестировать нужно в настоящих браузерах, в максимально похожем на реальность окружении.
В этом докладе будем говорить о том, как совместить все эти требования и не потратить много месяцев на построение собственного "велосипеда". Предлагается рабочее решение задачи с использованием open source решения WebPagetest Private Instance. Рассмотрим основные достоинства и проблемы решения, а также способы использования этого инструмента.
Как сделать ваш JavaScript быстрее / Роман Дворнов (Авито)Ontico
JavaScript, который мы пишем, не всегда исполняется, как мы думаем. Виртуальные машины, исполняющие его, делают многое, чтобы он работал быстрее. Но они не всесильны, и чтобы сделать код действительно быстрым, нужно знать их особенности и как все работает под капотом.
Поговорим об этих особенностях, что может служить причиной потери производительности, как это диагностировать и как делать код действительно быстрым. Доклад базируется на опыте, полученном в ходе работы над такими проектами как basis.js (весьма быстрый фреймворк для SPA), CSSO (минификатор CSS, который из медленного стал один из самых быстрых), CSSTree (самый быстрый детальный CSS парсер) и других.
Artisto: опыт запуска нейросетей в production / Эдуард Тянтов (Mail.ru Group)Ontico
Artisto - первое в мире мобильное приложение для обработки видео с помощью нейросетей в стиле картин художников и любых исходных изображений. Приложение вошло в топы AppStore и Google Play в США.
В рамках доклада расскажу:
- как научить нейросети рисовать, а, главное, красиво и быстро;
- про особенности переноса стиля на видео;
- про технологический стек.
Жизнь проекта на production советы по эксплуатации / Николай Сивко (okmeter.io)Ontico
Ваш сайт или другой проект приносит деньги только тогда, когда он работает.
Нельзя просто выложить код на серверы, залить схему в базу данных и делегировать домен.
Будем говорить о планировании отказоустойчивости и мониторинге проектов:
- оцениваем риски отказа различных компонентов;
- какие-то из вероятных проблем просто мониторим и планируем действия при сбоях;
- проблемы, которых можно избежать легко и дешево, закрываем сразу.
Расскажу на примерах о том, что всё всегда ломается, но с этим можно жить.
noBackend, или Как выжить в эпоху толстеющих клиентов / Самохвалов НиколайOntico
Набирает обороты мода на парадигму noBackend (см., например, http://nobackend.org/). Название не стоит понимать буквально: backend никуда не делся, просто фокус разработки — особенно на начальном этапе развития нового проекта — сильно смещается в сторону «клиентской части». Это очень понятно и закономерно в эпоху Mobile First и React Ecosystem с её новомодными GraphQL и React Native.
Появляется большой соблазн взять что-то понятное для хранения данных и уже «обвязанное» REST API, максимально отказаться от PHP/Python/Ruby/Java/etc, писать 80% кода «на стороне клиента», минимально заботясь о возне «на стороне сервера». У некоторых возникает и настоящая эйфория — чувство приятное, но очень опасное (прежде всего, если в команде нет сильного backend-опыта).
Этот доклад — компиляция опыта ряда проектов, написанных на React, React Native и Swift и переходящих на парадигму (или же сразу стартанувших с неё) noBackend за счёт PostgreSQL+PostgREST.
Мы обсудим важные вопросы, которые обязан задавать себе каждый, выбравший noBackend-подход (и не обязательно на связке Postgres+PostgREST): безопасность (аутентификация/авторизация; ограничение чтения и — особенно! — модификации «чужих» данных), производительность (нетривиальные запросы а-ля «свежий контент от тех, на кого я подписан»; компромисс между сетевой сложностью и CPU; защита от «домашнего» ddos — ситуации, когда свои же, родные «фронтендеры» кладут «бэкэнд»), масштабируемость и асинхронная обработка задач.
Задача-минимум (для всех): у каждого слушателя остаётся список must-check-вопросов для работы с noBackend-подходом.
Задача-максимум (для тех, кто с Postgres-опытом): разворачивание безопасного, высокопроизводительного и годного для быстрого развития REST API — сегодня же, в день док
Владимир Алаев "Разработка на Node.js: инструменты, библиотеки, сервисы"Yandex
Платформа Node.js становится все более популярной. Для нее уже создано много библиотек и инструментов. Рассказ о том, какие из них и для чего мы используем.
Одноклассники состоят из тысяч серверов, большая часть которых участвует в онлайн обработке запросов пользователей. Каждый из этих серверов владеет только частью данных или логики. Эти части в социальной сети изолировать друг от друга невозможно, поэтому между серверами происходит много сетевого взаимодействия, разнообразного и большого по объему. Таким образом, Одноклассники - это одна из самых больших, сложных и нагруженных распределенных систем в мире.
В этом докладе я расскажу об опыте построения отказоустойчивых распределенных систем на Java, основных ошибках и отказах, приемах их тестирования и диагностики. Также поговорим об авариях в распределенных системах и методах их предупреждения.
Слайды к первой лекции курса операционные системы в МГТУ им. Н.Э.Баумана.
Видео можно посмотреть на канале http://www.youtube.com/playlist?list=PLjSDyY6BQPVe2Zhxew5rJy2S-2_9t1vvn
При проектировании нагруженных систем приходится сталкиваться с тем, что разные типы запросов к веб-серверам затрачивают разное количество ресурсов, выполняются за разное количество времени и имеют разные приоритеты выполнения. Некоторые запросы «стоят» мало и должны выполняться как можно быстрее. Некоторые «стоят» дорого, и главное, чтобы они не блокировали обработку быстрых запросов. Существующие схемы приоритезации показались нам громоздкими и неудобными – при росте количества типов запросов конфигурация системы усложнялась в разы. Поэтому, чтобы решить эту проблему, а также для того, чтобы сделать ответы на запросы еще более быстрыми, мы написали свой веб-сервер – Phantom. Я расскажу вам, как он устроен, покажу, какие задачи можно решать с его помощью, а в завершение покажу на практике, как работает приоритезация разных типов запросов, используя для этого инструмент нагрузочного тестирования, основанный на Phantom.
Заседание научно-практического семинара, организованного ВМК МГУ и ИСП РАН 18 декабря 2014 года. Темой семинара стала операционная система ReactOS.
Видео этой презентации: http://www.youtube.com/watch?v=o68BZ2GT-FM
Веб-сайт ОС ReactOS: http://www.reactos.org
Группа ВК: https://vk.com/reactos_ru
Производительность Unity3D: подводные камни / Алексей Чубарь (BIT.GAMES)Ontico
Unity3D - это внушительный набор средств для кроссплатформенной разработки игр и 3D-приложений. Однако ряд его особенностей может привести к внезапному падению производительности продукта на мобильных платформах.
Где же прячутся подводные камни? Как обеспечить оптимальный user experience на старом смартфоне? Каких "граблей" стоит избегать при написании кода и подготовке графики? Рассмотрим на примере RPG "Гильдия Героев" для Android и iOS.
JavaScript, который мы пишем, не всегда исполняется, как мы думаем. Виртуальные машины, исполняющие его, делают многое, чтобы он работал быстрее. Но они не всесильны, и чтобы сделать код действительно быстрым, нужно знать их особенности и как все работает под капотом.
Поговорим об этих особенностях, что может служить причиной потери производительности, как это диагностировать и как делать код действительно быстрым. Доклад базируется на опыте, полученном в ходе работы над такими проектами как basis.js (весьма быстрый фреймворк для SPA), CSSO (минификатор CSS, который из медленного стал один из самых быстрых), CSSTree (самый быстрый детальный CSS парсер) и других.
Модным ныне словом «виртуализация» сейчас называют различные обёртки аппаратной виртуализации, однако этот термин намного старше и более всеохватывающий. На уровне ознакомления с технологией мы поговорим о виртуализации ресурсов в кластере и на примере pacemaker.
Владимир Алаев "Разработка на Node.js: инструменты, библиотеки, сервисы"Yandex
Платформа Node.js становится все более популярной. Для нее уже создано много библиотек и инструментов. Рассказ о том, какие из них и для чего мы используем.
Одноклассники состоят из тысяч серверов, большая часть которых участвует в онлайн обработке запросов пользователей. Каждый из этих серверов владеет только частью данных или логики. Эти части в социальной сети изолировать друг от друга невозможно, поэтому между серверами происходит много сетевого взаимодействия, разнообразного и большого по объему. Таким образом, Одноклассники - это одна из самых больших, сложных и нагруженных распределенных систем в мире.
В этом докладе я расскажу об опыте построения отказоустойчивых распределенных систем на Java, основных ошибках и отказах, приемах их тестирования и диагностики. Также поговорим об авариях в распределенных системах и методах их предупреждения.
Слайды к первой лекции курса операционные системы в МГТУ им. Н.Э.Баумана.
Видео можно посмотреть на канале http://www.youtube.com/playlist?list=PLjSDyY6BQPVe2Zhxew5rJy2S-2_9t1vvn
При проектировании нагруженных систем приходится сталкиваться с тем, что разные типы запросов к веб-серверам затрачивают разное количество ресурсов, выполняются за разное количество времени и имеют разные приоритеты выполнения. Некоторые запросы «стоят» мало и должны выполняться как можно быстрее. Некоторые «стоят» дорого, и главное, чтобы они не блокировали обработку быстрых запросов. Существующие схемы приоритезации показались нам громоздкими и неудобными – при росте количества типов запросов конфигурация системы усложнялась в разы. Поэтому, чтобы решить эту проблему, а также для того, чтобы сделать ответы на запросы еще более быстрыми, мы написали свой веб-сервер – Phantom. Я расскажу вам, как он устроен, покажу, какие задачи можно решать с его помощью, а в завершение покажу на практике, как работает приоритезация разных типов запросов, используя для этого инструмент нагрузочного тестирования, основанный на Phantom.
Заседание научно-практического семинара, организованного ВМК МГУ и ИСП РАН 18 декабря 2014 года. Темой семинара стала операционная система ReactOS.
Видео этой презентации: http://www.youtube.com/watch?v=o68BZ2GT-FM
Веб-сайт ОС ReactOS: http://www.reactos.org
Группа ВК: https://vk.com/reactos_ru
Производительность Unity3D: подводные камни / Алексей Чубарь (BIT.GAMES)Ontico
Unity3D - это внушительный набор средств для кроссплатформенной разработки игр и 3D-приложений. Однако ряд его особенностей может привести к внезапному падению производительности продукта на мобильных платформах.
Где же прячутся подводные камни? Как обеспечить оптимальный user experience на старом смартфоне? Каких "граблей" стоит избегать при написании кода и подготовке графики? Рассмотрим на примере RPG "Гильдия Героев" для Android и iOS.
JavaScript, который мы пишем, не всегда исполняется, как мы думаем. Виртуальные машины, исполняющие его, делают многое, чтобы он работал быстрее. Но они не всесильны, и чтобы сделать код действительно быстрым, нужно знать их особенности и как все работает под капотом.
Поговорим об этих особенностях, что может служить причиной потери производительности, как это диагностировать и как делать код действительно быстрым. Доклад базируется на опыте, полученном в ходе работы над такими проектами как basis.js (весьма быстрый фреймворк для SPA), CSSO (минификатор CSS, который из медленного стал один из самых быстрых), CSSTree (самый быстрый детальный CSS парсер) и других.
Модным ныне словом «виртуализация» сейчас называют различные обёртки аппаратной виртуализации, однако этот термин намного старше и более всеохватывающий. На уровне ознакомления с технологией мы поговорим о виртуализации ресурсов в кластере и на примере pacemaker.
Доклад от Parallels:
Методики тестировния производительности database-centric приложений
Описание: При работе над сложными продуктами в database-centric приложениях изменения в коде и тем более в SQL запросах к базе данных могут приводить к неожиданным падениям производительности или же деградации производительности приложения с ростом размера базы данных. Поэтому важно уметь как можно быстрее отлавливать и исправлять причины таких деградаций.
Доклад о том, как устроен процесс мониторинга производительности продукта автоматизации хостинга и облачных сервисов Parallels Automation, для которого определяющим фактором является производительность базы данных.
Компания покажет, как анализирует планы исполнения SQL запросов внутри PostgreSQL, как проверяет насколько быстро и эффективно в целом работают SQL запросы, как определяет стратегию дальнейшей оптимизации.
Подходы и технологии, используемые в разработке iOS-клиента Viber, Кирилл Лаш...Yandex
Рассказ об основных принципах, которых придерживается Viber в длительной разработке приложения с большой кодовой базой — если разработкой занимается распределённая команда. Мы обсудим используемые технологии, библиотеки, работу с кодом и многое другое.
20 апреля, DEV {highload}, "Демоны в большом проекте – проблемы и их решения ...IT-Portfolio
20 апреля, DEV {highload} - конференция о Highload веб-разработке, "Демоны в большом проекте – проблемы и их решения (Redis, RabbitMQ, Skytools, Node.JS, HBase)", Александр Чистяков (ведущий разработчик Cezurity)
Аннотация
Когда команда разработчиков собирается написать новый сервис, у нее, как правило, отсутствует свободное время, но есть необходимый энтузиазм. Из-за нехватки времени многие архитектурные решения приходится принимать, руководствуясь общими соображениями, так как провести всесторонние тесты имеющихся на рынке средств в краткие сроки невозможно. Мы, специалисты компании Cezurity, начали свой проект не вчера, и уже накопили некоторый опыт использования технологий, появившихся сравнительно недавно - таких как Skytools, Node.JS, RabbitMQ и Redis. О том, какие возникли проблемы при внедрении этих средств, и какие их ограничения пришлось преодолевать и учитывать - мой доклад. Кроме того, я расскажу о новом направлении в нашей деятельности - внедрении HBase для хранения большого объема данных.
Биография
Докладчик - узкий специалист широкого профиля, относит себя к виду, называемому в современной англоязычной литературе термином "DevOps". Любит принимать участие в создании сложных систем и постоянно это делает. Никогда не работал в Яндексе, компенсировав это работой в Mail.Ru и некоторых других местах.
This talk is an introduction about technical aspects of how payment cards function, what technical protocols are involved and what are implementation complexities in a typical payments project. You will learn about concepts like Authorisation and Clearing, Tokenization and know about novelties in the payment world, which will affect consumers in the nearest future.
Как построить свой фреймворк для автотестов?Dmitry Buzdin
Мы пройдемся по всем основным блокам построения тестового фреймворка и тому, как они связаны между собой. Вы научитесь собирать свое решение по автоматизации из библиотек с открытым кодом и делать так, чтобы они дополняли друг друга.
Microservices created quite a buzz in software development. Those are finally being adopted, and a lot of project suffer from that... microservices bring a lot of infrastructure and distributed programming complexity not all organisations can cope with. Question is – is it possible to gradually migrate to microservices architecture without Big Bang/Rewrite From Scratch approach? I would say it is possible, and is a much better idea compared to installing Kubernetes on AWS on day one. This talk is based on practical experience of architecting business applications to scale out and grow up to become micro services one day.
How to Build Your Own Test Automation Framework?Dmitry Buzdin
Even though there are plenty of open source tools on the market every company needs to put them together and create a test automation framework on top. Best practices of doing that are quite well-known in industry and it is important to learn them before building your own framework. We will go through the core building blocks of test automation frameworks and how they are playing together. You will learn how to assemble your test automation toolchain out of open source libraries and how to integrate them together. The session will be heavily biased towards Java platform.
3. О чём у нас
• Отвечаем на вопросы по Java Performance
– В основном, предварительно собранные в разных местах Рунета
– Есть возможность задать вопрос прямо здесь
• Пишем на бумажке, передаём вперёд ;)
• Сначала вводные слова про:
– Performance Engineering
– Startup
– JIT
– Concurrency and synchronization
• Другие сессии:
– “Искусное тестирование производительности (Java)”, завтра, 11-45
– “Диагностика и настройка GC”, сегодня, только что закончилось
– “JDK7”, параллельно с нами
3
5. Performance Engineering
абстрактно и отлично об отличиях в абстракциях
• Computer Science → Software Engineering
– Строим приложения по функциональным требованиям
– В большой степени абстрактно, в “идеальном мире”
• Теоретически неограниченная свобода – искусство!
• Можно строить воздушные зАмки
– Рассуждения при помощи формальных методов
• Software Performance Engineering
– “Real world strikes back!”
– Исследуем взаимодействие софта с железом на типичных данных
• Производительность уже нельзя оценить
• Производительность можно только измерить
– Естественно-научные методы
5
6. Performance Engineering
первый шаг
• Классические ошибки первого шага
– “я вижу, что метод foo() реализован неэффективно”
– “по профилю видно, что метод bar() – самый горячий и занимает 5%”
– “по-моему, у нас тормозит БД, и необходимо перейти с DBX на DBY”
• Правильный первый шаг:
– Необходимо выбрать метрику
• ops/sec, transactions/sec
• время исполнения
• время отклика
– Убедиться в корректности метрики
• релевантна (учитывает реальный сценарий работы приложения)
• повторяема
ЦЕЛЬ → улучшение метрики!
6
7. Performance Engineering
анализ узких мест (tips)
• Низкая утилизация CPU
– Высокая дисковая, сетевая активность
– Конфликт блокировок
– Конфликт ресурсов ОС
– Слабая параллелизация приложения
• Высокая утилизация ядра ОС
– Частые блокировки
– Частое обращение к ОС
• Высокая утилизация CPU
– Неоптимальная архитектура приложения
– Неправильное использование API
– Неоптимизированные горячие методы
– Неоптимальные настройки GC
7
8. Performance Engineering
инструменты для анализа системы
Solaris Linux Windows Что смотрим
Сеть netstat, dtrace netstat perfmon количество
соединений, объем
трафика
Диск iostat, dtrace iostat perfmon количество
обращений к диску,
задержка
Память vmstat, prstat, vmstat, top perfmon подкачка страниц,
dtrace размер памяти
Процессы ps, vmstat, mpstat, ps, vmstat, top perfmon количество нитей,
prstat, dtrace состояние нитей,
переключения
контекста
Ядро ОС mpstat, lockstat, vmstat perfmon kernel time,
plockstat, dtrace, блокировки,
intrstat, vmstat системные вызовы,
прерывания ...
8
9. Performance Engineering
tools, tools, tools again, more tools
• VisualVM
– http://visualvm.dev.java.net
• JRockit Mission Control
– http://www.oracle.com/technetwork/middleware/jrockit/mission-control/index.html
• Sun Studio Analyzer
– http://www.oracle.com/technetwork/server-storage/solarisstudio/overview/index.html
• DTrace
– http://www.oracle.com/technetwork/systems/dtrace/dtrace/index.html
• Ещё могут быть полезны:
– JProbe
– OptimizeIt
– YourKit
9
11. JVM tuning
настройка параметров JVM
• JVM сама подбирает оптимальные параметры своей работы
– Server vs. Client
– Large pages (Solaris)
– CompressedOops (64-bit VM)
• Так что же настраивать?
– GC/Heap tuning
– -XX:+UseNUMA (Solaris, Linux)
– -XX+:UseLargePages (Linux, Windows)
• http://www.oracle.com/technetwork/java/javase/tech/largememory-jsp-137182.html
• Не забыть
– Использовать последнюю версию JDK
11
20. Startup
длинные приложения
• Важно только для коротких приложений
– Чем дольше работает приложение, тем меньше удельные затраты на загрузку
классов и компиляцию
• Пример: 8 часа работает IntelliJ IDEA 10.x:
– 26.600 классов загружено
– 5315 методов скомпилировано
– Загрузка классов:
• Всего потрачено 202 с., ~0.7% общего времени
• 10 мсек на класс
– Компиляция:
• Всего потрачено 112 с., ~0.03% общего времени
• 20 мсек на метод
20
22. Concurrency
общие соображения
• Только мы научились программировать, новая беда
– Новое входное данное в программе: время
– Подавляющее большинство concurrency-багов – гейзен-баги!
• TDD “отдыхает”
• • Читаем хорошие книги
– “Учиться, учиться и ещё раз учиться” (с)
– “Java Concurrency in Practice”
– “The Art Of Multiprocessor Programming”
– “JSR 133 Cookbook”
– “A Little Book of Semaphores”
• Пользуемся высокоуровневыми примитивами
– java.util.concurrent.*
– ... или другими, построенными на их основе
22
24. JIT
факты
• … есть
• … работает
• … работает хорошо
• … знает о железе всё:
– Количество и тип CPU, поддерживаемые инcтрукции (SSEx, AVX, VIS)
– Топологию памяти (в т.ч. размеры кэшей и их характеристики)
• … знает о приложении много всего:
– Иерархию загруженных классов
– Актуальную статистику создания объектов
– Горячий код
– Какие ветвления исполнялись, какие значения использовались
• … не боится использовать эти знания для компиляции
24
26. JIT
performance urban legends
final дает лучшую
производительность
копируйте поля в
локальные переменные!
Reflection – volatile запрещает JIT
дорого оптимизировать доступ
к полю
вызов виртуального
метода - дорого избегайте get/set вручную вылизанный метод
методов внутри лучше аналога из classlib
самого класса
immutable классы –
плохо вручную выполненый
native методы дорогие, System.arraycopy() inline – хорошо
нативный – значит ...
Java медленна потому, что нельзя вручную создание объектов дорого –
выключить проверку выхода индекса за используйте Object pooling
границы массива
26
27. JIT
как писать код
• Используйте стандартные библиотеки
– Зачем писать собственный стандартный контейнер?
• Используйте высокоуровневый API:
– java.util.*, java.util.concurrent.*, NIO, NIO.2
– вообще библиотеки
• Код должен правильным и понятным
– Сначала правильно, потом алгоритмически “быстро”
– Код не должен быть JIT-oriented
• Правильно используйте возможности языка
– EPIC FAIL: штатная передача управления exception'ами
– FAIL: Возврат “исключения” через return <код_ошибки>
– FAIL: int вместо Enum или boolean
27
28. JIT
для любопытных
• Как получить ассемблерный код метода?
• Обычным дебаггером ;)
• JVMTI
• -XX:+PrintAssembly
– http://wikis.sun.com/display/HotSpotInternals/PrintAssembly
28
32. Performance Engineering
итеративный подход
Измерения
(эксперименты)
Разработка Сбор и обработка данных
Старт (кодирование решений) (профилировка, статистика)
Поиск решений
Анализ узких мест
(прототипирование)
Важно:
–Одно изменение за цикл!
–Документировать все изменения
32
34. Performance Engineering
”нисходящий” метод поиска узких мест
• Уровень системы
– Сеть
– Диск
– Database
– Операционная система
– Процессор/память
• Уровень приложения
– Блокировки, синхронизация
– Execution Threads
– API
– Алгоритмические проблемы
• Уровень JVM
– Выбор JVM
– Heap tuning
– JVM tuning
34
35. Java 7, Java 8
что ожидать в области производительности
• Java 7
– invokedynamic
– NIO.2
– Concurrency and Collection updates (Fork/Join)
– XRender pipeline for Java2D (client)
• Java 8 (или позже)
– Модульность
– λ-выражения (замыкания)
– Collection updates (filter, map, reduce)
35
36. Обратная совместимость
• Мешает ли улучшать производительность JVM?
– Да, поэтому иногда расширяемся:
• invokedynamic
• Модульность
• Стоит ли расширяться по первому требованию?
– Нет, развитие JVM/JIT, реализация новых методов оптимизации
позволяет получить бОльший выигрыш
• Вложенные классы
• Reflection
36
37. Лучшая ОС для Java
угадайте, какая?
Solaris
• Высокопроизводительный TCP/IP стек
– low-latency
– up to 50% faster
• DTrace
– мониторинг
• NUMA
– MPO, Memory Placement Optimization
• Large Pages
– Автоматическая аллокация
– Разные размеры
37
38. Concurrency
элементная база
• OS Threading
– мьютексы
• mutex_lock()/mutex_unlock()
– conditional waits
• cond_wait()/cond_signal()
• WaitForSingleObject
• Compare-and-Swap (CAS)
– CAS(x1, x2, x3) = { if (x1 == x2) { x1 = x3 }; }
– атомарная операция, поддерживаемая в “железе”: из нескольких одновременных
CAS'ов успешно завершается только один
– Миф: локальный CAS блокирует шину, и стоит больше на многопроцессорных
системах
– Факт: глобальный CAS требует трафика на шине
38
39. Concurrency
atomics
• java.util.concurrent.Atomic*
– обеспечивают атомарные операции над примитивами и указателями
– альтернатива: synchronized {} или Lock'и
• Трюк в использовании CAS'а:
– Изменение состояния атомика делается при помощи одного CAS'а
– Чтение состояния не требует CAS'а
mov %ecx,%edx
public final int incrementAndGet() { mov 0x8(%ecx),%eax
for (;;) { lea 0x8(%ecx),%edi
int current = get(); mov %eax,%ecx
int next = current + 1; inc %ecx
if (compareAndSet(current, next)) lock cmpxchg %ecx,(%edi)
return next; mov $0x0,%ebx
} jne [ok]
} mov $0x1,%ebx
test %ebx,%ebx
je [ok]
39
40. Concurrency
volatile
• Volatile определяет порядок чтения-записей в поле
– НЕ обеспечивает атомарности
– Реализуется расстановкой барьеров
• Какие из них вставятся в код, зависит от Hardware Memory Model
• Эффект барьера зависит от HMM
PUSHL EBP
SUB ESP,8 push %ebp
MOV EBX,[ECX + #12] sub $0x8,%esp
MEMBAR-acquire mov 0xc(%ecx),%ebx
MEMBAR-release inc %ebx
INC EBX mov %ebx,0xc(%ecx)
MOV [ECX + #12],EBX lock addl $0x0,(%esp)
MEMBAR-volatile add $0x8,%esp
LOCK ADDL [ESP + #0], 0 pop %ebp
ADD ESP,8 test %eax,0xb779c000
POPL EBP ret
TEST PollPage,EAX
RET
40
41. Concurrency
intrinsic synchronization
• synchronized(object) { }, 4 состояния:
– Init
– Biased
• Захватывается одним “владеющим” потоком, нет конфликтов
• Захват владельцем: проверка на threadID
• Захват не-владельцем: переход либо в Biased, либо в Thin
– Thin
• Захватывается несколькими потоками, но конфликтов нет
• Захват: CAS
• Конфликтный захват: переход в Fat
– Fat
• Захватывается несколькими потоками, конфликт на блокировке
• Вызов примитива синхронизации из ОС
41
42. Concurrency
java.util.concurrent.Lock
• Построены на базе j.u.c.AbstractQueueSynchronizer
– Использует CAS
– Использует Unsafe.park()/unpark() → cond_wait()/cond_signal()/WaitForSingleObject()
• ReentrantLock
– По семантике эквивалентен synchronized {}
– Ставит потоки во внутреннюю очередь и делает park()
– Non-Fair (default)
• Не гарантирует отсутствие starvation, ибо barging FIFO (CAS)
• Лучшая производительность
– Fair
• Гарантирует отсутствие starvation, FIFO
• Честность в обмен на производительность
42
43. Concurrency
атомарный счётчик
private AtomicInteger atomic = new AtomicInteger();
private ReentrantLock lock = new ReentrantLock();
private final Object intrinsicLock = new Object();
private int primCounter = 0;
@GenerateMicroBenchmark
public void testAtomicInteger() {
atomic.incrementAndGet();
}
@GenerateMicroBenchmark
public void testReentrantLock() {
lock.lock();
primCounter++;
lock.unlock();
}
@GenerateMicroBenchmark
public void testIntrinsicLock() {
synchronized (intrinsicLock) {
primCounter++;
}
}
43
45. Concurrency
ReentrantLock vs. synchronized
• Семантика одинакова
– Требования к видимости памяти
– Рекурсивный
• Плюсы j.u.c.RL
– Очередь потоков держится на стороне JVM
• опционально, FIFO-политика при захвате-освобождении
• позволяет быть “честным” на любой платформе
– Barging FIFO policy
• lock() может быть сразу удовлетворён, даже если в очереди есть потоки
• сильно улучшает производительность при конфликте блокировок
– Допускается несколько Condition
• Минусы j.u.c.RL
– Нет scope'ов, требуется ручной unlock() через finally
45
48. The preceding is intended to outline our general product
direction. It is intended for information purposes only,
and may not be incorporated into any contract. It is
not a commitment to deliver any material, code, or
functionality, and should not be relied upon in making
purchasing decisions.
The development, release, and timing of any features
or functionality described for Oracle’s products remains
at the sole discretion of Oracle.
48