Я развернул несколько простых сервисов в качестве подтверждения концепции: веб-сервер nginx с исправлением https://stackoverflow.com/a/8217856/735231 для высокой производительности.
Я также отредактировал /etc/nginx/conf.d/default.conf, чтобы строка listen 80;становится listen 80 http2;.
Я использую инструмент распределенного нагрузочного тестирования Locust с классом, который меняет модуль requests на hyper для тестирования рабочих нагрузок HTTP / 2.Это не может быть оптимальным с точки зрения производительности, но я могу порождать многих саранчовых, поэтому это не большая проблема.
Для тестирования я создал кластер на GKE из 5 машин, 2 vCPU, 4 ГБ ОЗУ каждая, установил Helm и графики этих сервисов (я могу опубликовать их в гисте позже, если это будет полезно).
Я протестировал Locust с min_time = 0 и max_time = 0, чтобы он порождал как можно больше запросов;с 10 работниками против одного экземпляра nginx.
С 10 работниками, всего 140 "клиентов", я получаю ~ 2,1 тыс. запросов в секунду (RPS).
10 workers, 260 clients: I get ~2.0k RPS
10 workers, 400 clients: ~2.0k RPS
Теперь я пытаюсьмасштабировать по горизонтали: я порождаю 5 экземпляров nginx и получаю:
10 workers, 140 clients: ~2.1k RPS
10 workers, 280 clients: ~2.1k RPS
20 workers, 140 clients: ~1.7k RPS
20 workers, 280 clients: ~1.9k RPS
20 workers, 400 clients: ~1.9k RPS
Использование ресурсов довольно низкое, как показано kubectl top pod (это для 10 работников, 280 клиентов; nginx не ограничен в ресурсах,рабочие саранчи ограничены одним ЦП на модуль):
user@cloudshell:~ (project)$ kubectl top pod
NAME CPU(cores) MEMORY(bytes)
h2test-nginx-cc4d4c69f-4j267 34m 68Mi
h2test-nginx-cc4d4c69f-4t6k7 27m 68Mi
h2test-nginx-cc4d4c69f-l942r 30m 69Mi
h2test-nginx-cc4d4c69f-mfxf8 32m 68Mi
h2test-nginx-cc4d4c69f-p2jgs 45m 68Mi
lt-master-5f495d866c-k9tw2 3m 26Mi
lt-worker-6d8d87d6f6-cjldn 524m 32Mi
lt-worker-6d8d87d6f6-hcchj 518m 33Mi
lt-worker-6d8d87d6f6-hnq7l 500m 33Mi
lt-worker-6d8d87d6f6-kf9lj 403m 33Mi
lt-worker-6d8d87d6f6-kh7wt 438m 33Mi
lt-worker-6d8d87d6f6-lvt6j 559m 33Mi
lt-worker-6d8d87d6f6-sxxxm 503m 34Mi
lt-worker-6d8d87d6f6-xhmbj 500m 33Mi
lt-worker-6d8d87d6f6-zbq9v 431m 32Mi
lt-worker-6d8d87d6f6-zr85c 480m 33Mi
Я изобразил этот тест на GKE для упрощения репликации, но я получил те же результаты в кластере частного облака.
Почему кажется, что не имеет значения, сколько экземпляров я порождаю для службы?
ОБНОВЛЕНИЕ : Согласно первому ответу, я обновляю информацию информацией об узлах ио том, что происходит с одним рабочим из саранчи.
1 worker, 1 clients: 22 RPS
1 worker, 2 clients: 45 RPS
1 worker, 4 clients: 90 RPS
1 worker, 8 clients: 174 RPS
1 worker, 16 clients: 360 RPS
32 clients: 490 RPS
40 clients: 480 RPS (this seems over max. sustainable clients per worker)
Но, прежде всего, кажется, что основная проблема заключается в том, что я нахожусь на пределе возможностей:
user@cloudshell:~ (project)$ kubectl top pod
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
gke-sc1-default-pool-cbbb35bb-0mk4 1903m 98% 695Mi 24%
gke-sc1-default-pool-cbbb35bb-9zgl 2017m 104% 727Mi 25%
gke-sc1-default-pool-cbbb35bb-b02k 1991m 103% 854Mi 30%
gke-sc1-default-pool-cbbb35bb-mmcs 2014m 104% 776Mi 27%
gke-sc1-default-pool-cbbb35bb-t6ch 1109m 57% 743Mi 26%