Трудовые будни инженера производительности

© 2015 NetCracker Technology Corporation Confidential
Трудовые будни performance engineer
Владимир Ситников
jokerconf university 2015

2© 2015 NetCracker Technology Corporation Confidential
Кто я
• Владимир Ситников
• Инженер-ускорятор в NetCracker
• sitnikov@netcracker.com
• @VladimirSitnikv

Характерные требования в enterprise
• Время отклика
‒ 100мс … 1с … 1ч
• Частота выполнений
‒ 1/день … 1/с … 100/с
• Объём обрабатываемых данных
‒ 10КиБ … 1Миб … 1ГиБ

Основная ошибка при проверке производительности
Проверку требований нужно выполнять на
приближенных к боевым условиях

• Та же версия java, OS, application server

• Тот же объём данных

• Та же входная нагрузка

• Та же входная нагрузка
• Тот же процент ошибочных сценариев

Проблемы в Production
• Создан работающий код
• Пройдено тестирование

• Production
Проблемы производительности,
недоступность приложения, и т.п.

• Production
• Customer Support передает проблему в System Performance

• Production
• Customer Support передает проблему в System Performance
• SP находит причину, и автор кода о ней не знает

Сложение строк
• StringBuilder vs StringBuffer
• String + String vs SB.append

Сложение строк
• StringBuilder vs StringBuffer
• Без разницы
• String + String vs SB.append
• В циклах лучше SB

Когда же нужен StringB***er?
String res = "";
String names[] = ...;
for(int i=0; i<length; i++) {
res += (i==0 ? "" : ", ") + names[i];
}
StringBuilder полезен в циклах/if’ах

String res = "";
res += new SB()
.append(i==0 ? "" : ", ")
.append(names[i]).toString();
}

StringBuilder res = new StringBuilder();
res
.append(i==0 ? "" : ", ")
.append(names[i]);
}

Добавляем вишенку
StringBuilder res = new StringBuilder(100500);
res
.append(i==0 ? "" : ", ")
.append(names[i]);
}

GC друг или враг?
• Основная масса проблем с java в enterprise – java GC или OS
swap

swap
• Для анализа всегда сохраняем логи работы GC: -Xloggc

swap
• Открываем программой GCViewer

swap
• Открываем программой GCViewer
• GC наносит ответный удар: лог пишется синхронно
• Не стоит размещать gc.log на сетевых дисках (NFS):
http://mail.openjdk.java.net/pipermail/hotspot-gc-use/2014-
April/001849.html

GCViewer: пример случая, когда «всё пропало»
• Без GC логов не понять хватило ли памяти

Где может встретиться regexp
• «Маскирование» (~засекречивание) данных:
pin коды, номера карт, …
• Обработка XML: логирование, проверка success/fail, …
• Много где ещё

Решили использовать regexp
Стоит избегать .*, .+ и подобных не специфичных конструкций
http://www.regular-expressions.info/catastrophic.html

Пример медленного выражения:
Pattern.compile(
"<(S+:)?processID.*>(d+)</(S+:)?processID>"

Пример медленного выражения:
Pattern.compile(
"<(S+:)?processID.*>(d+)</(S+:)?processID>"
Встречались экземпляры, работающие 30 секунд на 100КиБ строке
Встречались SQL запросы, работающие по 30 минут вместо 30 секунд

Чиним
Стоит избегать .*, .+ и подобных неспецифичных конструкций
Пример быстрого выражения:
Pattern.compile(
"[:<]processID[^>]*>(d+)</([^>:]+:)?processID>"
Решение: [^>]* и [^>:]+ остановятся на первом неподходящем
символе. За границу xml тэга наш regexp не уйдёт.

Чиним ещё чуть-чуть
Добавляем плюсик для отмены откатов:
Pattern.compile(
"[:<]processID[^>]*+>(d+)</([^>:]++:)?processID>“
Меньше вариантов на проверку – быстрее работает

График скорости .*, .*?, [^>]
0
100
200
300
400
1 КиБ 2 КиБ 3 КиБ 4 КиБ
Быстрее,оп/мс
.*
.*?
[^>]*

График скорости .*, .*?, [^>], шаблон не найден
0
10
20
30
40
50
.*
.*?
[^>]*
Поиск тормозил, т.к.
шаблон не нашёлся

График скорости .*, .*, [^>], шаблон не найден
0
20
40
60
80
100
.*
.*?
[^>]*
(?>
<ROW>(?>.*?<RSACCTNMBR>)
(?>[^<]*</RSACCTNMBR>)…

Признаки хорошего регулярного выражения
• Кушает только нужные символы
• [^>]* vs .*
• .(!=hello)

• [^>]* vs .*
• .(!=hello)
• Не содержит лишних конструкций
• <MACd{5} vs (<MACd{5}s)

• [^>]* vs .*
• .(!=hello)
• Не содержит лишних конструкций
• <MACd{5} vs (<MACd{5}s)
• Не выполняется вообще
• Например, если мы маскируем значения, то делать это нужно только если
реально выводим данные
• Если XML всё равно парсить, то стоит посмотреть на XPath

А давайте ускорим String?
String.format("...") использует
java.util.regex.Pattern для разбора формата
formatSpecifier = "%(d+$)?([-#+
0,(<]*)?(d+)?(.d+)?([tT])?([a-
zA-Z%])";

Откуда взять тестовые данные?
Возьмём шаблон из Java Microbenchmark
Harness:
(min, avg, max) = (%s, %s, %s), stdev = %s%n
CI (99.9%%): [%s, %s] (assumes normal
distribution)

Добавляем плюсов по вкусу
formatSpecifier = "%(d+$)?([-#+
0,(<]*)?(d+)?(.d+)?([tT])?([a-
zA-Z%])";
fastSpecifier = "%(d++$)?+([-#+
0,(<]+)?+(d++)?+(.d++)?+([tT])?+([a-zA-
Z%])";

Бесплатный сыр
Benchmark Cnt Score Error Units
jdk18u45 60 1,067 ± 0,025 us/op
optimized 60 0,917 ± 0,021 us/op

HashMap$Entry
• HashMap создаёт вспомогательные Entry объекты для
хранения связки ключ-значение

HashMap$Entry
• HashMap создаёт вспомогательные Entry объекты для
хранения связки ключ-значение
• Если большинство ключей оказываются одинаковыми,
то очень хочется не хранить ключи в каждом
отдельном объекте Map

HashMap
HashMap Entry[]
Entry
id
41
Entry
name
qwe

HashMap: entry лишние
HashMap Entry[]
Entry
id
41
Entry
name
qwe

HashMap
HashMap Entry[]
Entry
id
41
Entry
name
qwe

CompactMap
CMap1 Object[]
41
qwe
CMap2
keypos
id=0
name=1
Object[]
42
rty

CompactHashMap: границы применимости
• Работает, если форма (состав ключей) у многих
объектов одинаковая
• Например, у всех объектов есть запись “width”=“100%”
• https://github.com/vlsi/compactmap
• См. v8/design.html#prop_access

CompactHashMap: первые тесты
HashMap -> CompactHashMap в реальном
проекте:
• 500МиБ –> 290МиБ
• 3.0 сек / 1M обращений -> 150 сек / 1M обращений

CompactHashMap
HashMap -> CompactHashMap в реальном
проекте:
• 500МиБ –> 290МиБ
• 3.0 сек / 1M обращений -> 150 сек / 1M обращений

ReservedCodeCacheSize
• Если у JIT компилятора заканчивается память,
то он перестаёт компилировать

• В приложении с большим количеством кода
стандартных 64M мало

• В приложении с большим количеством кода
стандартных 64M мало
• -XX:+ReservedCodeCacheSize=128m/192m

CompactHashMap
HashMap -> CompactHashMap, -
XX:+ReservedCodeCacheSize=128m:
• 500МиБ –> 290МиБ
• 3.0 сек / 1M обращений -> 3.5 сек / 1M обращений

SQL

Типичные проблемы в SQL
• Выборка лишних данных
• max(order_number)+1, count(*)>0, большая иерархия
• Нет ясного порядка выполнения запроса
• Лишние таблицы в части FROM
• Неверное использование связанных переменных

Один запрос – один правильный план выполнения
1. В “Folder for Orders” найти Order, ссылающийся на нужный Instance
Как бы решал человек:
1. По ссылкам находим ордера, и проверяем Folder

2. В “Service Order’е” найти компоненту, ссылающуюся на нужный
Template
Как бы решал человек:
2. Находим дочерние компоненты и проверяем Template
10
101

Задачи:
1. В “Folder for Service Orders” найти Service Order, ссылающийся на нужный
Service Instance
2. В “Service Order’е” найти компоненту, ссылающуюся на нужный Template
В обоих случаях может получиться одинаковый запрос (например, EAV):
select o.object_id
from objects o, references ref
where o.parent_id = :1
and o.object_id = ref.object_id
and ref.reference = :2
and ref.property = :3

• Разработчик должен хотя бы задумываться о плане выполнения
• Без explain plan никуда

• Если в запросе несколько условий, то хинты обязательны

• Если в запросе несколько условий, то хинты обязательны
• Основные хинты:
• leading(a b c) – указываем с каких таблиц начинать
выполнение запроса
• index(o index_name) – указываем какой индекс нужно
использовать
• no_merge – запрещаем раскрывать подзапросы
• use_nl/use_hash – основные способы объединения таблиц

А нужны ли хинты?
•База умная,
сама ускорит запросы

•База умная, статистику собрали,
сама ускорит запросы

собираем статистику регулярно,
запросы сами будут хорошие

собираем статистику регулярно,
запросы сами будут хорошие
база не понимает бизнес-смысл 
•Без хинтов не взлетит

А нужна ли тогда статистика?
•Если всё равно хинты, то зачем
статистика?

• Повторяемость production и dev/test
окружений

• Повторяемость production и dev/test
окружений
• Отсутствие out-of-thin air проблем

А как же любимые cost/rows?
• База оценивает количество строк на основе собранной статистики

• В статистику входят
• Общее количество строк
• Количество уникальных записей в колонке
• Количество null записей в колонке

• Rows – оценка базы о том, сколько строк вернёт запрос
• Cost – оценка базы о том, сколько дисковых операций потребуется
для выполнения запроса

• База оценивает количество строк на основе собранной
статистики
• Бизнес-смысл данных в статистику не входит!
• Rows – оценка базы о том, сколько строк вернёт запрос
• Cost – оценка базы о том, сколько дисковых операций
потребуется для выполнения запроса

Кто я
• Владимир Ситников
• Инженер-ускорятор в NetCracker
• sitnikov@netcracker.com
• @VladimirSitnikv

Спасибо

Трудовые будни инженера производительности

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Трудовые будни инженера производительности

Similaire à Трудовые будни инженера производительности (20)

Трудовые будни инженера производительности

Notes de l'éditeur