ZuulException REJECTED_SEMAPHORE_EXECUTION — последнее часто встречающееся исключение при тестировании производительности. Данные запроса найдены, потому что Zuul по умолчанию изолирует каждый маршрут напрямую семафором, а значение по умолчанию равно 100, то есть, когда семафор запроса маршрута выше 100, он откажет в обслуживании и вернет 500.
Изоляция семафора
Поскольку значение по умолчанию слишком мало, увеличьте семафор каждого маршрута в конфигурации шлюза, а затем поэкспериментируйте.
routes:
linkflow:
path: /api1/**
serviceId: lf
stripPrefix: false
semaphore:
maxSemaphores: 2000
oauth:
path: /api2/**
serviceId: lf
stripPrefix: false
semaphore:
maxSemaphores: 1000
Семафор двух отдельных маршрутов увеличен до 2000 и 1000. Затем мы проводим тест Гатлинга.
setUp(scn.inject(rampUsers(200) over (3 seconds)).protocols(httpConf))
Это наша модель, запускающая 200 пользователей за 3 секунды, последовательно обращающихся к 5 API. Таким образом, будет 1000 запросов. Конфигурация машины имеет только 2 ядра и 16G, и это докеризованная база данных. Так что общая производительность не высока.
Глядя на результаты, по-прежнему 57 КО, но это намного лучше, чем предыдущее соотношение 900 КО на 1000 запросов.
изоляция резьбы
Edgware
Версии весеннего облака предоставляют другой механизм изоляции на основе пула потоков. Это также очень просто реализовать,
zuul:
ribbon-isolation-strategy: THREAD
thread-pool:
use-separate-thread-pools: true
thread-pool-key-prefix: zuulgw
hystrix:
threadpool:
default:
coreSize: 50
maximumSize: 10000
allowMaximumSizeToDivergeFromCoreSize: true
maxQueueSize: -1
execution:
isolation:
thread:
timeoutInMilliseconds: 60000
use-separate-thread-pools
означает, что каждый маршрут имеет свой собственный пул потоков вместо совместного использования.thread-pool-key-prefix
Префикс пула потоков будет указан для облегчения отладки.hystrix
Часть в основном устанавливает размер пула потоков, здесь установлено 10000, на самом деле, чем больше, тем лучше. Чем больше пул нитей, тем значительнее эффект срезания пиков и заполнения впадин, то есть время для пространства. Общая нагрузка на систему будет увеличиваться, что приведет к увеличению времени отклика.Когда время отклика превышает определенный предел, система фактически становится непригодной для использования. Данные можно посмотреть позже.
На этот раз 500 нет, а 1000 запросов возвращаются нормально.
Сравнивать
Сравните эффекты двух изоляций на нескольких рисунках: верхний рисунок — изоляция семафора, а нижний рисунок — изоляция потока.
распределение времени отклика
Интуитивно можно обнаружить, что раздача с использованием изоляции потоков выглядит лучше, а отклик в пределах 600мс будет больше.
QPS
Две цифры показывают количество запросов и ответов одновременно.
Сначала посмотрите на сценарий изоляции семафора, отклик в секунду постепенно увеличивается, но по достижении порядка шлюз начинает отказываться от обслуживания. Угадайте, лимит семафора превышен или истекло время ожидания?
Изоляция потоков более интересна: вы можете видеть, что количество запросов в секунду растет быстрее, чем указано выше, что указывает на то, что система пытается получить больше запросов и распределить их по пулу потоков. В какой-то момент времени Response per second начал снижаться, потому что непрерывное создание потоков потребляло много системных ресурсов и отклик становился медленнее. После этого из-за того, что запросов стало меньше, нагрузка уменьшилась, а Response снова начал расти. Поэтому пул потоков не настолько велик, насколько это возможно, и приходится постоянно отлаживать, чтобы найти точку баланса.
резюме
Пул потоков обеспечивает лучший механизм изоляции, чем семафор, и в реальном тесте было обнаружено, что в сценариях с высокой пропускной способностью может быть выполнено больше запросов. Однако накладные расходы на изоляцию семафора меньше, и для самой системы в пределах 10 мс семафор, очевидно, больше подходит.