Недавно я узнал о сценариях, которые требуют разогрева приложения (с высокой пропускной способностью), прежде чем они начнут обслуживать реальные запросы. Логика этого заключалась в том, чтобы позволить JIT делать свою магию производительности!Разбавление высокопроизводительных приложений Java
Является ли это нормой для приложений Java или обычно это делается для приложений с большой памятью (размером)?
Если вы говорите о веб-сайте/веб-сайте с высоким трафиком, тогда JIT является очень незначительной проблемой. Самая большая проблема - разогревать (заполнять) все уровни кеша, которые вам понадобятся. Например, ehcache regions which are being populated from hibernate. Это потому, что связанные с IO операции порядков медленнее, чем все, что происходит внутри процессора (то есть, если вы не счетные фракталы :)
+1 для «если вы не вычисляете фракталы». – z5h
Спасибо за указатель, но я думаю, что я имел в виду разогрев кодовых путей, а не «дорогих» данных. Мне было особенно интересно, было ли целесообразно, чтобы большие Java-приложения были предварительно разогреты, особенно учитывая, что JVM сегодня достаточно умны, чтобы решить, к какому пути кода обращаются много, и, следовательно, кэшировать JIT для них и т. Д. Конечно, есть перфорация. ударил, когда JITing в первый раз, и, следовательно, я хотел знать, если в реальной жизни кто-то столкнулся с этой проблемой, которая бы побудила их разогреть свои приложения, и если да, то какие перф. улучшения видели они. –
@Aayush Puri: и я ответил, что если вы говорите о webapp, то JIT-разминка составляет 0,01%, поэтому в реальной жизни (и в контексте webapps) у всех есть большие проблемы для решения (разминка для базы данных, кешей и т. Д.) – cherouvim
Вопрос заключается в том, когда вы хотите, чтобы выйти из своего пути, чтобы сделать это ?
Если вы развернете webapp, и это НЕМЕДЛЕННО жить, то пока вы его «согреваете», вы добавляете дополнительную нагрузку, что является контрпродуктивным. Аналогично, когда запускается настольное приложение. Нет смысла нагреваться, если пользователь начнет немедленно его использовать. Или, что еще хуже, не позволяет пользователю взаимодействовать, пока вы согреваете приложение.
Если вы развернете webapp, и вы проверите развертывание, прежде чем указывать на него балансиры нагрузки, то вы уже согрели его как побочный результат.
Лично, _I_ будет сходить с пути, чтобы сделать это, когда я выполняю тесты производительности. Или когда у меня есть кластер, и разогрев машины, прежде чем подключать его к кластеру, это не влияет на пользователей. –
Но если ваша производственная среда не имеет преимущества разогрева, почему вы хотите перекосить результаты теста производительности, прогреваясь в среде тестирования производительности? – zkarthik
Я полностью согласен с тем, что только разумно разогреть приложение, прежде чем добавлять его в свой балансировщик нагрузки. –
В дополнение к cherouvim's answer, я могу думать о нескольких других вопросов, требующих прогрева:
Xms меньше вашего Xmx).Я полагаю, что ОС также настроена на поведение приложения, так что на вызовы ОС также может влиять период разминки.
Большинство из вышеперечисленных (кэширование, инициализация объекта) не относятся к Java.
+1: Население файлов файловых кэшей может быть большим фактором. – erickson
> Распределение кучи (если ваш Xms меньше вашего Xmx). Хорошая точка. И я считаю, что именно поэтому говорят, что Xmx = Xms –
Настройка производительности - это меньше о «изучении сценариев», чем измерение и анализ того, что происходит в ** ваших ** конкретных сценариях. – flybywire
См. Также мой вопрос: http://stackoverflow.com/questions/1481853/technique-or-utility-to-minimize-java-warm-up-time – noahlz