Глубокое осмысление QPS, TPS, RT, параллелизма, понимания пропускной способности и оптимизации производительности.

Java
Глубокое осмысление QPS, TPS, RT, параллелизма, понимания пропускной способности и оптимизации производительности.

пропускная способность

Прежде чем понять, что такое qps, tps, rt и параллелизм, мы должны сначала уточнить, что означает пропускная способность системы — максимально допустимое количество посещений пользователей.

Пропускная способность системы обычно определяется qps (tps) и числом параллелизма. Каждая система имеет относительный предел для этих двух значений. Пока определенный элемент достигает максимального значения, пропускная способность системы не будет увеличиваться. .

QPS

Запросов в секунду (количество запросов в секунду) – это количество запросов, на которые можно ответить в секунду. Обратите внимание, что здесь под запросом понимается количество раз, когда пользователь отправляет запрос на сервер для успешного ответа. В простом понимании , можно считать, что запрос = запрос запрос.

qps=Количество запросов в секунду

TPS

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

Для целей одиночных интерфейсов TPS можно считать эквивалентным QPS, например, доступ к странице /index.html является TPS, а доступ к странице /index.html может запрашивать три раза сервер, например css, js, index интерфейсов, было произведено три QPS.

tps = транзакций в секунду

RT

Аббревиатура времени отклика, просто понимаемая как интервал времени от ввода до вывода системы, В широком смысле это представляет собой разницу во времени с момента, когда клиент инициирует запрос, до момента, когда сервер получает запрос и отвечает на все данные. Обычно берется среднее время ответа.

параллелизм

Короче говоря, количество запросов/транзакций, которые система может обрабатывать одновременно.

Расчет

QPS=параллельность/RT или Concurrency=QPS*RT

Возьмите каштан:

Предположим, что в компании 3600 сотрудников, которым необходимо сходить в туалет в течение часа с 9:00 до 10:00 утра, а среднее время посещения туалета каждым сотрудником составляет 10 минут, посчитаем.

QPS = 3600/60*60 1

ВР = 10*60 600 секунд

Параллелизм = 1 * 600 600

Это означает, что если вы хотите получить наилучшие впечатления от приседаний, компании необходимо 600 ям для удовлетворения потребностей сотрудников, в противном случае вам придется стоять в очереди, чтобы сходить в туалет.

производительное мышление

Согласно формуле QPS = количество одновременных операций / RT, предполагая, что мы сейчас однопоточные сценарии, формула QPS должна выглядеть так: QPS = 1 / RT, фактически RT должно = время процессора + время ожидания процессора, если число потоков увеличится до 2 , тогда QPS = 2 / (время процессора + время ожидания процессора), то это означает, что мы просто увеличить количество потоков может улучшить QPS это?

Расчет оптимального количества потоков

Если предположить, что время ЦП равно 49 мс, а время ожидания ЦП равно 200 мс, тогда QPS=1000 мс/249 мс=4,01, где время ожидания 200 мс можно считать тем, что ЦП находился в состоянии ожидания и ничего не делал. 200мс еще может принять 200/49≈ 4 запросов, без учета переключения контекста и прочих накладных расходов, можно считать, что общее количество потоков = (200+49)/49=5.Если рассматривать вопрос многоядерности процессора и использование, мы можем примерно предположить, что:

**Оптимальное количество потоков = RT/CPUTime ✖️Количество ядер ЦП ✖️Загрузка ЦП **

Тогда максимальная формула QPS выводится как:

Максимальное число запросов в секунду = оптимальное количество потоков✖️Однопотоковое количество запросов в секунду = (RT/время ЦП ✖️Количество ядер ЦП ✖️Использование ЦП)✖️(1/RT) = Количество ядер ЦП✖️Использование ЦП/Время ЦП

Значит ли это, что мы можем бесконечно увеличивать количество запросов в секунду, пока мы продолжаем увеличивать количество ядер ЦП?

Закон Амдала

Г. М. Амдал предложил закон Амдала в 1967 году, который дает модель масштабируемости параллельной обработки, указывая на то, что ускорение использования параллельной обработки определяется той частью задачи, которую можно распараллелить. Мы можем просто понимать его как значение ускорения, которое программа теоретически может получить за счет дополнительных вычислительных ресурсов.

par — доля параллельных вычислений, p — количество узлов параллельной обработки

Предположим, вы хотите поехать из Ванцзина в Шуньи, ехать на машине нужно 3 часа, хотя сейчас там 3 машины, за 1 час туда не добраться. Здесь нет параллелизма, все Par=0%, p=3, коэффициент ускорения по-прежнему равен 1, а скорость не улучшается.

Закон Густафсона Густафсона

Закон Стаффона, также известный как масштабированное ускорение, объясняет взаимосвязь между количеством процессоров, серийным коэффициентом и ускорением, но отличается от закона Амдала.

Согласно закону Амдала и формуле расчета количества запросов в секунду, когда время ЦП и загрузка ЦП остаются неизменными, увеличение числа ядер ЦП может увеличить максимальное число запросов в секунду. Когда параметр не равен 0 или параллелен, увеличение числа параллельных вычислений p может повысить эффективность. но на самом деле по мере увеличения количества запросов это приводит к большому количеству переключений контекста, изменений gc и lock. Чем выше qps, тем больше объектов генерируется, тем чаще происходит gc, и это влияет на время и загрузку процессора.Особенно в последовательном времени вращение блокировки, самоадаптация, смещение и т. д. также становятся факторами, влияющими на пар.

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

Ссылаться на:

javahao123.com/?p=772

cloud.Tencent.com/developer/ ах…

woo woo woo.cn blog on.com/ просто следуйте/…

woohoo.brief.com/afraid/8532AC88От…

zhuanlan.zhihu.com/p/66929848

woo woo woo.cn blog on.com/Lu Peng2010/…

  • END -