Что вы описываете, это «Настройка производительности». Когда мы говорим о настройке производительности, есть два угла к этому. (a) Время ответа - сколько времени занимает выполнение конкретного запроса / программы. (b) Пропускная способность - сколько запросов он может выполнить за секунду. Когда мы обычно «оптимизируем» - когда мы исключаем ненужную обработку, улучшается как время отклика, так и пропускная способность. Однако, если у вас есть события ожидания в вашем коде (например, Thread.sleep (), ожидание ввода-вывода и т. Д.), На ваше время отклика влияют, но на пропускную способность не влияют. Принимая параллельную обработку (порождая несколько потоков), мы можем улучшить время отклика, но пропускная способность не улучшится. Обычно для серверного приложения важны время отклика и пропускная способность. Для настольных приложений (таких как IDE) пропускная способность не важна, важно только время отклика.
Вы можете измерить время отклика с помощью «Тестирования производительности» - вы просто записываете время отклика для всех ключевых транзакций. Вы можете измерить пропускную способность с помощью «нагрузочного тестирования» - вам нужно непрерывно накачивать запросы от достаточно большого количества потоков / клиентов, чтобы загрузка ЦП серверного компьютера составляла 80-90%. Когда мы прокачиваем запрос, нам нужно поддерживать соотношение между различными транзакциями (так называемая комбинация транзакций) - например, в системе резервирования будет 10 бронирований на каждые 100 поисковых запросов. на каждые 10 бронирований и т. д. будет одна отмена.
После определения транзакций, требующих настройки времени отклика (тестирование производительности), вы можете определить горячие точки с помощью профилировщика.
Вы можете определить «горячие точки» для пропускной способности, сравнив долю времени отклика этой транзакции. Предположим, в поиске, бронировании, отмене сценария соотношение составляет 89: 10: 1.
Время отклика составляет 0,1 с, 10 с и 15 с.
нагрузка для поиска - 0,1 * .89 = 0,089
нагрузка для бронирования - 10 * .1 = 1
нагрузка для cancell = 15 * .01 = 0,15
Здесь настройка бронирования даст максимальное влияние на пропускную способность.
Вы также можете определить «горячие точки» для пропускной способности, многократно получая дампы потоков (в случае приложений на основе Java).