Ошибки, отображаемые k6 при достижении большего количества виртуальных пользователей

Question

Я оцениваю k6 для моих нагрузочных испытаний. Я настроил базовый c нагрузочный тест, и в настоящее время я пытаюсь интерпретировать сообщения об ошибках и полученные результаты. Может быть, кто-то может помочь мне интерпретировать то, что я вижу:

Если я подниму VUS примерно до 300, я начну видеть сообщения об ошибках в консоли и 500 сообщений об ошибках.

В основном они состоят из:

• tcp набора XXX: 443: тайм-аут ввода-вывода
• чтение tcp YYY (локальный ip): 35252-> XXX (ip хоста): 443: чтение : сброс соединения по пиру
• level = warning msg = «Ошибка запроса» = «неожиданный EOF»
• Get https://REQUEST_URL / : превышен крайний срок контекста »

У меня также есть проблемы с несколькими проверками:

• проверка ошибок, в которых res.status === 0 и res.body === null
• проверка ошибки, в которых res.status === 0, но тело содержит правильное содержимое

Как может res.status быть 0, но тело все еще содержит правильные значения?

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

Статистика k6 показывает длинные значения http_req_blocked, которые я интерпретирую как время ожидания получения порта подключения. Похоже, это указывает на то, что пул подключений моей тестовой машины на пределе.

http_req_blocked...........: avg=5.66s    min=0s    med=3.26s    max=59.38s p(90)=13.12s   p(95)=20.31s 
http_req_connecting........: avg=1.85s    min=0s    med=280.16ms max=24.27s p(90)=4.2s     p(95)=9.24s  
http_req_duration..........: avg=2.05s    min=0s    med=496.24ms max=1m0s   p(90)=4.7s     p(95)=8.39s  
http_req_receiving.........: avg=600.94ms min=0s    med=82.89µs  max=58.8s  p(90)=436.95ms p(95)=2.67s  
http_req_sending...........: avg=1.42ms   min=0s    med=35.8µs   max=11.76s p(90)=56.22µs  p(95)=62.45µs
http_req_tls_handshaking...: avg=3.85s    min=0s    med=1.78s    max=58.49s p(90)=8.93s    p(95)=15.81s 
http_req_waiting...........: avg=1.45s    min=0s    med=399.43ms max=1m0s   p(90)=3.23s    p(95)=5.87s 

Может кто-нибудь помочь мне интерпретировать результаты, которые я вижу?

Answer 1

Скорее всего, у вас заканчивается процессор на бегуне. Как объяснено в http Speci c метриках документации , вы правы насчет http_req_durtion (это в основном) время, когда мы говорим, что хотим сделать запрос, когда мы получаем сокет, для которого сделать это. Скорее всего, это связано с тем, что:

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

Вам нужно будет следить за ними (настоятельно рекомендуется делать это независимо от), так как тестирование на 100% бегущих ЦП, вероятно, не очень представительно :) и вы, вероятно, не хотите, чтобы тестируемая система также достигала 100%.

Код состояния === 0 означает, что мы не смогли сделать запрос / прочитать ответ ... для некоторых причина, обычно объясняемая error и error_code.

Как я прокомментировал, если у вас есть код состояния 0 и тело, это, скорее всего, ошибка ... по крайней мере, я не помню, чтобы был случай, когда это не будет правдой.

Имеющиеся в списке ошибки означают (скорее всего):

dial tcp XXX:443: i/o timeout

Это буквально мы пытались установить TCP-соединение, и это заняло слишком много времени (вероятно, причина большого http_req_blocking)

read tcp YYY(local ip):35252->XXX(host ip):443: read: connection reset by peer

другая сторона закрыла соединение ... вероятно, из-за истечения некоторого времени ожидания - например, если мы не читаем более 30 секунд, сервер решает, что мы больше не будем читать, и закрывает его. ... и в случае, когда CPU равен 100%, есть большая вероятность, что какое-то соединение не получит время для чтения.

level=warning msg="Request Failed" error="unexpected EOF"

буквально, как говорится ... соединение было закрыто, когда мы полностью не ожидал, или, точнее, golang net / http stdlib не ожидал. Вероятно, снова тайм-аут только в тот момент в жизни запроса, когда другие ошибки не возвращаются.

Get https://REQUEST_URL/: context deadline exceeded"

Это потому, что запрос занял больше времени, чем тайм-аут (по умолчанию 60 с), и в какой-то момент изменится на лучшее сообщение об ошибке .