Мы, программисты, тратим часы на кодирование приложения, составляя тысячи строк кода и тестируя их. Мы постоянно рефакторим код для оптимизации производительности.

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

Это все произошло со мной недавно, когда я работал над устаревшим приложением, содержащим более 200 классов, и каждый из них содержал не менее 1000 строк кода.

На основе структуры Struts 1.3, архитектуры Maven, Java 7, JSP и MVC , в этом приложении отсутствовали юнит-тесты (что было для меня очень неожиданно).

Приложение работало как ухо поверх Jboss 7.1.1 в течение многих лет, но, конечно, у него есть свои недостатки, которые конечные пользователи обнаружили постепенно.

Когда я взялся за приложение, у меня было несколько встреч с конечными пользователями, на которых они поделились своим разочарованием по поводу многих его аспектов. Это был беспорядок! Но и возможность сделать что-то лучше.

Я начал анализировать его и увидел довольно много возможностей для рефакторинга, просто обновив версию Java до 11, чтобы я мог использовать поток Java 8. методы коллекции, компактная строка Java 9 и многое другое. Все они все еще находятся в разработке, и я поделюсь с ними своим опытом в следующих статьях.

Но внедрение Graal стало прорывом в стремлении к быстрому повышению производительности, так как требовалось только изменение конфигурации на сервере приложений и изменение компиляции Java в коде, а также добавление отсутствующей зависимости Jax B.

Кроме того, это дало мне возможность использовать Java Mission Control для анализа различных аспектов оценки производительности, таких как Использование ЦП, кучная память и Использование молодого поколения, Управление потоками, Загрузка классов, Использование метапространства и Сбор мусора.

Технические аспекты оценки производительности:
1. ЦП:Intel(R) Core(TM) i7–8665U CPU @ 1,90 ГГц, производитель: GenuineIntel

2. ОС:Windows 10.0, 64-разрядная версия

3. Graal: Graalvm-ce-java11–21.2.0, версия для сообщества.

4. JDK: JDK 1.8

5.Сервер приложений: Wildfly 18.0

Критерии оценки эффективности:

Оценка производительности выполняется для модуля приложения, который, как сообщается, был очень медленным при выполнении операций с базой данных над миллионами записей, таких как:

а) выбор 200632 записей по нескольким критериям, их обновление.

б) выбрать 200632 записи, отфильтровать из них 28512 записей и удалить их.

c) обновление состояния 172 120 записей.

Показатели оценки эффективности:

Использование ЦП:

Точка доступа не показывает загрузку ЦП, поэтому было невозможно узнать, сколько ЦП было загружено Java-приложениями.

Принимая во внимание, что Graal сообщил о 14,2% использования ЦП, что является вполне желаемой производительностью.

Распределение пространства кучи:

Анализ пространства кучи показывает, что Graal использует меньше памяти в куче, чем Hotspot, почти 64% использования памяти кучи в Hotspot.

Кроме того, Graal выделяет больше места для памяти молодого поколения по сравнению с Hotspot, что облегчает создание объектов.

Метапространство и загрузка классов:

Выделение из метапространства связано с загрузкой класса. Когда класс загружается и готовится его представление во время выполнения в JVM, его загрузчик класса выделяет метапространство для хранения метаданных класса.

Здесь мы видим, что Graal использует больше метапространства, поэтому загружает больше классов, чем Hotspot, чтобы обеспечить более высокую пропускную способность.

Как и Hotspot, Graal также использует Уровневую компиляцию с использованием компиляторов C1 и C2. Однако, будучи написанным на Java с нуля, Graal добавляет расширенный JIT-оптимизирующий компилятор в виртуальную машину HotSpot Java.

(Функция опережающего компилятора будет также рассмотрена в следующих статьях).

Использование темы:

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

Однако оптимальное использование потоков полностью зависит от того, как спроектировано ваше приложение.

Соотношение времени GC и параллелизм:

Точка доступа по умолчанию выделяет 99% времени для пропускной способности приложения и 1% для сборки мусора.

Здесь по умолчанию Graal выделяет 76,9% времени для пропускной способности приложения и 23,1% для сборки мусора, т.е. балансируя распределение времени между пропускной способностью (создание нового объекта, перемещение постоянных объектов в старое поколение) и сборкой мусора (удаление неиспользуемых объектов).

Однако тот же параметр GC можно явно применить и к активной области.

Что касается параллельности, Graal применяет 2 параллельных потока для сборки мусора по сравнению с 0 в Hotspot для повышения производительности.

Заключение

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

Есть отзывы? Пожалуйста, дайте мне знать в разделе комментариев или напишите мне по адресу [email protected].