Как оптимизировать JVM и GC с помощью нагрузочного тестирования
Редактировать : Из нескольких чрезвычайно щедрых и полезных ответов, которые уже были получены на этот вопрос, для меня очевидно, что я не давал Важная часть этого вопроса ясна, когда я задал его сегодня утром. Ответы, которые я получил до сих пор, больше касаются оптимизации приложений и устранения узких мест на уровне кода .Я понимаю, что это гораздо важнее, чем пытаться получить дополнительные 3–5% от вашей JVM!
В этом вопросе предполагается, что мы уже сделали практически все, что могли, для оптимизации архитектуры нашего приложения на уровне кода. Теперь нам нужно больше, и следующее место, куда нужно обратить внимание, - это уровень JVM и сборка мусора; Я соответствующим образом изменил заголовок вопроса. Спасибо еще раз!
У нас есть бэкэнд-архитектура в стиле «конвейера», в которой сообщения передаются от одного компонента к другому, причем каждый компонент выполняет разные процессы на каждом этапе пути.
Компоненты находятся внутри файлов WAR, развернутых на серверах Tomcat. Всего у нас в конвейере около 20 компонентов, находящихся на 5 разных серверах Tomcat (я не выбирал архитектуру или распределение WAR для каждого сервера). Мы используем Apache Camel для создания всех маршрутов между компонентами, эффективно формируя «соединительную ткань» конвейера.
Меня попросили оптимизировать сборщик мусора и общую производительность каждого сервера, на котором запущена JVM (всего 5). Я потратил несколько дней на изучение сборщика мусора и настройки производительности и довольно хорошо разбираюсь в том, что делает каждый из различных параметров JVM, как организована куча и как большинство параметров влияют на общую производительность JVM. .
Я считаю, что лучший способ оптимизировать каждую JVM - это , а не , чтобы оптимизировать ее как отдельную.Я «чувствую» (насколько я могу это оправдать!), Что попытка локально оптимизировать каждую JVM без учета того, как она будет взаимодействовать с другими JVM на других серверах (как восходящих, так и нисходящих), не приведет к глобально оптимизированному решению. .
Для меня имеет смысл оптимизировать весь конвейер в целом. Итак, мой первый вопрос: ТАК согласен, а если нет, то почему?
Для этого я думал о создании LoadTester , который будет генерировать входные данные и передавать их на первую конечную точку. в стадии разработки. Этот LoadTester может также иметь отдельный « Monitor Thread », который будет проверять пропускную способность последней конечной точки. Затем я мог бы выполнять все виды обработки, при которых мы проверяли среднее время сквозного прохождения сообщений, максимальную пропускную способность до отказа и т. Д.
LoadTester генерировал бы тот же образец входных сообщений в и снова. Переменной в этом эксперименте будут параметры JVM, передаваемые параметрам запуска каждого сервера Tomcat. У меня есть список из примерно 20 различных вариантов, которые я хотел бы передать JVM, и решил, что могу просто настраивать их значения, пока не найду почти оптимальную производительность.
Возможно, это не лучший способ сделать это, но это лучший способ, который я мог бы разработать, используя то время, которое мне было отведено для этого проекта (около недели).
Второй вопрос: что ТАК думает об этой установке? Каким образом SO может создать «оптимизирующее решение» по-другому?
И последнее, но не менее важное: мне любопытно, какие метрики я мог бы использовать в качестве основы для измерения и сравнения.На самом деле я могу только думать о:
- Найдите конфигурацию опции JVM, которая обеспечивает самое быстрое среднее время сквозного прохождения сообщений
- Найдите конфигурацию опции JVM, которая обеспечивает наибольшую пропускную способность тома без сбоя любого из серверов
Есть другие? Есть ли причины, по которым эти 2 плохие?
Изучив игру, я мог понять, как это может быть истолковано как монолитный вопрос, но на самом деле я спрашиваю, как SO будет оптимизировать JVM, работающие вдоль конвейера, и чувствовать себя свободным чтобы разрезать и нарезать мое решение, как вам это нравится.
Заранее спасибо!