Волгин Т.А.

[TimaVolgin]

Initial Commit:
Анализ данных производится на 15 минутном временном интервале:

CPU загружен примерно на 11-12% и иногда поднимается до 14%
В программе наблюдается memory leak, так как со временем график используемой памяти HEAP постепенно растет и после срабатывания GC размер используемого HEAP не падает до изначального значения.
Первая сборка мусора в Old Generation происходит через 12 минут, HEAP падает с 130мб до 20мб
Eden Space в HEAP скачет в диапазоне +-10-15мб, график в виде пилы
Запуск сценария 1 в среднем занимает 0,041 секунды и это время в среднем растет на 0,001 за 2-3 секунды

С помощью Sampler было выявлено, что больше всего процессорного времени занимает операции:
AccountDAOImpl.getAllAccounts()
AccountService.getAccount()
AccountDAOImpl.getAccountByUser()
AccountService.getAllAccounts()

Анализ memory показывает, что больше всего создается объектов типа int[], char[], java.lang.Object[], byte[]

Анализ с помощью Profiler показал, что в топе функции:
H2DAOFactory.getConnection()
AccountService.getAllAccounts()
model.User.ToString()
model.Account.ToString()
service.UserService.getAllUsers()

Далее оптимизация с помощью Sampler и Profiler описана по пунктам (ШАГ №)

ШАГ 0.

CPU ~ 13%
Сборка мусора происходит раз в 10 минут, диапазон от 100 до 30 мб.
Запуск ~ 0,05 секунды, за 10 секунд время увеличивается на 0,001 секунды
AccountDAOImpl.getAllAccounts() ~ больше всего времени потребляет при вызове из AccountDAOImpl.getAccountByUser()

Убираем лишний вызов getAllAccounts() и просто возвращаем acc

ШАГ 1.

CPU ~ 11%
В топе UserDAOImpl.getAllUsers()

Убираем добавление в неиспользуемую коллекцию fetched

ШАГ 2.

CPU ~ 10%
В топе UserDAOImpl.getAllAccounts()

Исправляем неудачную реализацию функции hashCode()

ШАГ 3.

CPU ~ 8%
Еще не оптимизированная функция в топе UserService.createUser(), в ней оптимизируем UserDAOImpl.insertUser()

Убираем вычисление id, очищаем ресурсы

ШАГ 4.

CPU ~ 5%
Еще не оптимизированная функция в топе UserService.getAllUsers()

Убираем неиспользуемую коллекцию allUsers

ШАГ 5.

CPU ~ 5%
В getAllAccounts заменили тип коллекции Set на List

ШАГ 6.

CPU ~ 4-5%
Used heap ~ в среднем 50 мб
Cреднее время отзыва на старте 0,043, увеличение на 0,001 за минуту
В модели заменили реализацию toString(), используя StringBuilder
Уменьшилось потребление памяти Used heap

Анализ данных после оптимизации на 15 минутном временном интервале:

CPU загружен в диапазоне 5-7%, иногда поднимается до 9%
memory leak в программе все еще наблюдается, т.к. растет график используемого HEAP size
Сборка мусора в Old Generation происходит раз в 4 минуты, Used HEAP при первой сборке падает с 150мб до 35мб
Eden Space скачет в диапазоне +-25мб, график в виде пилы
Запуск сценария 1 в среднем занимает 0,036 секунды и это время растет на 0,001 за 18 секунд и постепенно этот интервал увеличивается, т.е. рост среднего времени отклика замедляется
Как видно из данных до/после оптимизации, в среднем на дистанции довольно сильно упало время отклика для сценария 1, что в свою очередь привело к более интенсивному потреблению памяти.

Реализации BD на HASHMAP дала незначительные изменения в показателях, CPU usage упал на 0.1%.

--GC--
Сравнение проводилось между G1GC, ParallelGC, SerialGC, UseConcMarkSweepGC.
Анализ на временном интервале ~ 12 минут.

Лучше всего себя показали SerialGC и UseConcMarkSweepGC. При их использовании на короткой дистанции (до 5 минут) практически незаметен memory leak. Более стабильное и низкое потребление CPU показал SerialGC // 5-6% SerialGC против 5-11% UseConcMarkSweepGC //, поэтому предпочтение стоит отдать SerialGC.
G1GC показал наихудшие результаты, очень быстро увеличивает объем потребляемой памяти HEAP, рост в 9 раз за 10 минут до 668 мб. При ограничении максимального объема памяти -Xmx120m -Xms120m через 9 минут нагрузка на процессор возросла вдвое до 24%
При использовании ParallelGC также хорошо заметен memory leak, полная сборка GC первый раз отрабатывает через 6 минут, при ограничении объема памяти -Xmx120m -Xms120m на дистанции сборка GC учащается. CPU used 6~7%.

[yarkinsv]

Тут можно было еще тогда уж стринг билдеру задать первоначальный размер буфера )