Привет

я всегда сначала смотрю трейс этой операции в NewRelic, если его недостаточно, то лезу в систему мониторинга, логи.. вплоть до снятия и анализа дампа

а вообще я думаю, что тут нет наиболее правильного ответа, наиболее корректного
вопрос скорее просто для того, чтобы узнать о том, а есть ли вообще у человека опыт анализа и решения проблем производительности на продакшене и какой

PetroNotC SharpДобится повторяемости ошибки на стенде. Потом локализовать проблему (опухоль).
и каким образом вы это делали?

PetroNotC SharpВы перепутали домашнюю ветку. Java прогеры этим не занимаются.
уверен, что занимаются :)

ещё раз повторю, что скорее всего вопрос задаётся, чтобы выяснить есть и какой у кандидата практический опыт
и на ответ "Добится повторяемости ошибки на стенде. Потом локализовать проблему" очевидно будет задан вопрос: "каким конкретно образом?"

иначе просто не логично вообще спрашивать про это :)
вместо этого бери да показывай человеку куда смотреть, что делать, кого звать

так не обсуждай, серъёзный ты наш :) зачем вообще ответил ТСу?

так и представил себе картину:

начинает тормозить REST API на продакшене, определённая операция.. SQL-запросы к БД выполняется быстро..
приходят к разработчику этого самого REST API и просят разобраться..

а он им в ответ:
- я серъёзный Java программист, я таким не занимаюсь!
- идите-ка сначала повторите ситуацию на стенде, локализуйте проблему, потом и приходите

maytonПравильный шаг - открыть логи и смотреть.
В логи чего конкретно? :)

REST API, в логах БД нет долгих запросов...

тут надо смотреть, начиная от балансировщика, конкретных серверов фермы и заканчивая кодом приложения...
кстати возникает встречный вопрос: а чем дигностировали внезапное появление тормозов?
если некая система мониторинга выдала предупреждение, то может в неё сначала и посмотреть?

maytonА где вообще описана архитектура?

Сейчас каждый из присутствующих. Как пенсионер в очереди поликлиники. Вспоминает и перечисляет свои болезни.
дык на мой взгляд от кандидата и ожидается рассказ именно о его опыте, со встречными вопросами типа "а какая у вас архитектура?"

И формулировку
j2ee2016Какой ответ Вы считаете наиболее правильным и корректным на вопросследует понимать не только как, что именно ответить, а ещё и как правильно и корректно выстроить разговор на данную тему

Андрей ПанфиловДмитрий Мухтут надо смотреть, начиная от балансировщика, конкретных серверов фермы и заканчивая кодом приложения...
кстати возникает встречный вопрос: а чем дигностировали внезапное появление тормозов?А чего к разработчику-то пришли? Еще бы у бухгалтера бы спросили...
а ты куда ходишь в таких случаях?

maytonЕще более правильный ответ. Позвонить в 1ю линию саппорта.wat?

Андрей ПанфиловДмитрий Мухпропущено...

а ты куда ходишь в таких случаях?Я никуда не хожу: за работу продуктовой среды несут ответственность вполне определенные команды/люди - вот пусть они и ходят, а ответственность обычного разработчика заканчивается где-то в районе тестовой среды, а если за каждого делать делать его работу, так и на свою времени не останется. Пусть воспроизводят проблему на той среде, к которой у разработчика есть полноценный доступ, тогда можно будет полноценно общаться.

что касается всяких APM, типа:Дмитрий Мухя всегда сначала смотрю трейс этой операции в NewRelic, если его недостаточно, то лезу в систему мониторинга, логи.. вплоть до снятия и анализа дампаЯ как-то их необходимостьюполезностью как-то не проникся совершенно: для разработчика там набор возможностей весьма скудный (ну вот например https://docs.newrelic.com/docs/integrations/host-integrations/host-integrations-list/oracledb-monitoring-integration вообще никуда не годится), а для заказчика там тоже чет все странно, например в случае мониторинга JVM алерты на дедлоки нужно руками настраивать, а не "оно само" ( https://discuss.newrelic.com/t/where-to-see-the-deadlocks-in-newrelic/58882/9), при этом заказчикам APM впаривают с апломбом "вот установите себе и у вас в миг все проблемы с производительностью решатся", забывая сказать что проблемы с производительностью решает разработчик, а не APM, поэтому если решателей в штате нет, то ничего и не решится. Я вообще сталкивался с довольно забавной ситуацией: заказчику впарили APM как раз в то время, когда активно шли работы по оптимизации одной из проблемных систем, в результате внедрятели APM тупо взяли и все заслуги приписали себе (типа внедрение APM увеличило производительность на 25%, ага)
Вот тоже хороший ответ. Отлично раскрывает опыт кандидата. И обоим сторонам быстро станет понятно, что к чему.