При настройке производительности необходимо следовать определенным принципам, иначе это может принести еще большую скрытую опасность. Ниже приведены 4 основных принципа, которые необходимо соблюдать.

1) Избегайте рисков.

Функциональный приоритет всегда выше производительности. Любая оптимизация производительности не может основываться на принесении в жертву функциональной корректности. В противном случае, чем выше производительность, тем больше потери.

2) Принцип бочонка.

Только решив один недостаток, можно выявить новые. В приложении может быть много точек оптимизации, но каждая точка оптимизации по-разному влияет на производительность. Необходимо определить, что является основной причиной снижения производительности. Только целенаправленное решение этой основной проблемы может дать реальные результаты. достигнуто улучшение производительности.

Например, в приложении имеется узкое место на диске, вызванное чрезмерным объемом журнала и проблемой восхождения на стек. В это время загрузка ЦП составляет 60%. Тогда уменьшение количества журналов в это время, переход на асинхронные журналы или обновление диска могут привести к значительным улучшениям.

Если вы решите только проблему сканирования, это не принесет особенно очевидного улучшения производительности. TPS можно улучшить только в том случае, если диск 10 не станет узким местом или если можно избежать проблем с блокировкой потоков за счет асинхронного журналирования.

Увеличение TPS приведет к более высокому потреблению ЦП, поэтому, когда ЦП станет узким местом, решение проблемы сканирования приведет к значительному увеличению TPS.

3) Оптимизировать оценку доходов.

С точки зрения технических специалистов любая точка оптимизации ценна, но для предприятий необходимо учитывать приоритет и экономическую эффективность точек оптимизации. Оптимизация производительности в первую очередь учитывает оптимизацию конфигурации, чтобы затраты были минимальными, а выгоды часто были высокими.

Во-вторых, рассмотрите оптимизацию логики кода, которую необходимо всесторонне оценить, исходя из количества изменений и цикла проекта. Если это может принести функциональные риски, а времени на регрессионное тестирование недостаточно, не рискуйте вносить изменения и лучше решите проблему. временно за счет расширения мощностей и других методов.

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

4) Умение использовать инструменты анализа производительности не означает умение их настраивать.

Конечная цель настройки производительности — решение проблем с производительностью. Инструменты важны, но идеи важнее.

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

Далее в качестве примера возьмем знакомый захват дампа. Многие новички думают, что после возникновения проблемы с производительностью они могут проанализировать проблему с производительностью, получив файл дампа. Но на самом деле это не так. Получение дампа также представляет собой сложную задачу, и необходимо учитывать две проблемы.

Прежде всего, дамп делится на дамп потока и дамп памяти. Итак, при каких обстоятельствах целесообразно собирать дамп потока и при каких обстоятельствах необходимо захватывать дамп памяти?

Проще говоря, если вы анализируете проблемы с высокой загрузкой ЦП или подозреваете исчерпание пула потоков, блокировку потоков и т. д., вы обычно просто получаете дамп потока. Если вы анализируете проблемы с памятью, такие как частая полная сборка мусора, или подозреваете утечки памяти, вам необходимо получить дамп памяти. Обратите внимание, что дамп памяти также можно использовать для анализа проблем потока, но стоимость дампа памяти выше, а время паузы, вызываемое приложением, больше. Поэтому, если дамп потока можно использовать для анализа, дамп потока определенно предпочтительнее.

Во-вторых, есть ли время схватить дамп?

Конечно, это зависит от того, какой тип проблемы с производительностью вы анализируете. Если это бесконечный цикл, взаимоблокировка или проблема 00M, можно также впоследствии получить дамп. Но если некоторые временные исключения возвращаются в норму, например, частый полный сборщик мусора (в настоящее время это не утечка памяти, память может быть переработана нормально, но количество полных сборщиков очень частое), вам необходимо использовать дамп памяти, чтобы проанализировать, какие объекты заняты. Памяти много, поэтому время захвата дампа очень важно. Если при получении дампа происходит полный сбор мусора, весьма вероятно, что часто создаваемые объекты не будут найдены в дампе.

Поэтому вам следует обратить внимание на размер файла после получения дампа памяти.

Например, если объем кучи составляет 1 ГБ, а размер файла дампа составляет всего 200 МБ, весьма вероятно, что в этот момент захвата только что произошел полный сбор мусора, а файл дампа не имеет значения для анализа, и подходящий файл дампа памяти необходимо поймать заново.

Наконец, мы используем изображение, чтобы полностью представить распространенные инструменты настройки производительности, как показано ниже:

Общие инструменты тестирования производительности

Если найдете что-нибудь полезное, жду вашего внимания! ! ! !