Мы, программисты, тратим часы на кодирование приложения, составляя тысячи строк кода и тестируя их. Мы постоянно рефакторим код для оптимизации производительности.
Иногда эта оптимизация возникает в результате самореализации, результатов тестовых случаев, отзывов тестировщиков. В большинстве случаев ваш клиент может потребовать от вас изучить любую область для лучшего взаимодействия с пользователем.
Это все произошло со мной недавно, когда я работал над устаревшим приложением, содержащим более 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].