Introdução
O lançamento v0.27.0 nos trouxe um novo mecanismo de execução e muitos novos executores para atender aos seus requisitos específicos. Ele também inclui uma nova API de script com muitas opções diferentes para ajustar e simular a carga do sistema em teste (SUT). Este é o resultado de um ano e meio de trabalho na famosa solicitação de pull # 1007 .
Para gerar consultas a uma taxa constante, podemos usar
constant-arrival-rate
artista. Este executor executa o teste com iterações em uma frequência fixa para o tempo especificado. Isso permite que o k6 altere dinamicamente o número de usuários virtuais ativos (VUs) durante a execução do teste para atingir o número especificado de iterações por unidade de tempo. Neste artigo, vou explicar como usar esse cenário para gerar solicitações a uma taxa constante.
Noções básicas de opções de configuração de script
Vamos dar uma olhada nos principais parâmetros usados no k6 para descrever uma configuração de teste em um script que usa um
constant-arrival-rate
executor:
- executor ():
— k6. VU - — , , . rate
()timeUnit
( ):
k6rate
timeUnit
.
:
rate: 1
,timeUnit: '1s'
« »rate: 1
,timeUnit: '1m'
« »rate: 90
,timeUnit: '1m'
« 90 », 1,5 /, 667 ,rate: 50
,timeUnit: '1s'
« 50 », 50 (requests per second — RPS), , .. 20
- duration ():
,gracefulStop
. preAllocatedVUs
:
.maxVUs
:
, .
Juntos, esses parâmetros formam um script que faz parte das opções de configuração de teste. O snippet de código abaixo é um
constant-arrival-rate
script de exemplo .
Nesta configuração, temos um
constant_request_rate
script, que é um identificador único usado como rótulo para o script. Este cenário usa um constant-arrival-rate
executor e é executado em 1 minuto. A cada segundo ( timeUnit
), 1 iteração ( rate
) será realizada . O pool de usuários virtuais pré-provisionados contém 20 instâncias e pode chegar a até 100, dependendo do número de solicitações e iterações.
Esteja ciente de que a inicialização de usuários virtuais durante um teste pode exigir muito da CPU e, portanto, distorcer os resultados do teste. Em geral, é melhor
preAllocatedVU
ter o suficiente para executar o teste de carga. Portanto, não se esqueça de alocar mais usuários virtuais, dependendo do número de solicitações em seu teste e da taxa na qual deseja executar o teste.
export let options = {
scenarios: {
constant_request_rate: {
executor: 'constant-arrival-rate',
rate: 1,
timeUnit: '1s',
duration: '1m',
preAllocatedVUs: 20,
maxVUs: 100,
}
}
};
Um exemplo de geração de solicitações com frequência constante com constant-arrival-rate
No tutorial anterior, demonstramos como calcular a taxa de solicitação constante. Vamos dar uma olhada nisso novamente, tendo em mente como funciona o script:
Suponha que você espera que seu sistema em teste lide com 1000 solicitações por segundo em um terminal. A pré-alocação de 100 usuários virtuais (máximo de 200) permite que cada usuário virtual envie aproximadamente 5 a 10 solicitações (com base em 100 a 200 usuários virtuais). Se cada solicitação leva mais de 1 segundo para ser concluída, você acaba fazendo menos solicitações do que o esperado (mais
dropped_iterations
), o que é um sinal de problemas de desempenho ou expectativas irrealistas para o sistema em teste. Se for esse o caso, você deve corrigir os problemas de desempenho e reiniciar o teste ou moderar suas expectativas ajustando timeUnit
.
Neste cenário, cada usuário virtual pré-alocado fará 10 solicitações (
rate
dividido porpreAllocatedVU
) Se as solicitações não forem recebidas em 1 segundo, por exemplo, levou mais de 1 segundo para obter uma resposta ou seu sistema em teste levou mais de 1 segundo para concluir a tarefa, k6 aumentará o número de usuários virtuais para compensar as solicitações perdidas. O teste a seguir gera 1.000 solicitações por segundo e é executado por 30 segundos, o que é cerca de 30.000 solicitações, como você pode ver na saída abaixo: http_reqs
e iterations
. Além disso, o k6 usou apenas 148 de 200 usuários virtuais.
import http from 'k6/http';
export let options = {
scenarios: {
constant_request_rate: {
executor: 'constant-arrival-rate',
rate: 1000,
timeUnit: '1s', // 1000 , ..1000
duration: '30s',
preAllocatedVUs: 100, //
maxVUs: 200, // preAllocatedVU , ,
}
}
};
export default function () {
http.get('http://test.k6.io/contacts.php');
}
O resultado deste script será o seguinte:
$ k6 run test.js
/\ |‾‾| /‾‾/ /‾/
/\ / \ | |_/ / / /
/ \/ \ | | / ‾‾\
/ \ | |‾\ \ | (_) |
/ __________ \ |__| \__\ \___/ .io
execution: local
script: test.js
output: -
scenarios: (100.00%) 1 executors, 200 max VUs, 1m0s max duration (incl. graceful stop):
* constant_request_rate: 1000.00 iterations/s for 30s (maxVUs: 100-200, gracefulStop: 30s)
running (0m30.2s), 000/148 VUs, 29111 complete and 0 interrupted iterations
constant_request_rate ✓ [======================================] 148/148 VUs 30s 1000 iters/s
data_received..............: 21 MB 686 kB/s
data_sent..................: 2.6 MB 85 kB/s
*dropped_iterations.........: 889 29.454563/s
http_req_blocked...........: avg=597.53µs min=1.64µs med=7.28µs max=152.48ms p(90)=9.42µs p(95)=10.78µs
http_req_connecting........: avg=561.67µs min=0s med=0s max=148.39ms p(90)=0s p(95)=0s
http_req_duration..........: avg=107.69ms min=98.75ms med=106.82ms max=156.54ms p(90)=111.73ms p(95)=116.78ms
http_req_receiving.........: avg=155.12µs min=21.1µs med=105.52µs max=34.21ms p(90)=147.69µs p(95)=190.29µs
http_req_sending...........: avg=46.98µs min=9.81µs med=41.19µs max=5.85ms p(90)=53.33µs p(95)=67.3µs
http_req_tls_handshaking...: avg=0s min=0s med=0s max=0s p(90)=0s p(95)=0s
http_req_waiting...........: avg=107.49ms min=98.62ms med=106.62ms max=156.39ms p(90)=111.52ms p(95)=116.51ms
*http_reqs..................: 29111 964.512705/s
iteration_duration.........: avg=108.54ms min=99.1ms med=107.08ms max=268.68ms p(90)=112.09ms p(95)=118.96ms
*iterations.................: 29111 964.512705/s
vus........................: 148 min=108 max=148
vus_max....................: 148 min=108 max=148
Ao escrever um script de teste, considere os seguintes pontos:
- k6 (), . , ,
maxRedirects: 0
. http ,maxRedirects
. - . , , , ,
sleep()
. - , , .
preAllocatedVU
/maxVU
, , , ,preAllocatedVU
,maxVU
.
WARN[0005] Insufficient VUs, reached 100 active VUs and cannot initialize more executor=constant-arrival-rate scenario=constant_request_rate
- ,
drop_iterations
,iterations
http_reqs
.dropped_iterations
, , . , ,preAllocatedVU
. , , , . - , , . :
WARN[0008] Request Failed
- Lembre-se de que a API de script não oferece suporte ao uso global de duração, vus e estágios, embora eles ainda possam ser usados. Isso também significa que você não pode usá-los em conjunto com scripts.
Conclusão
Antes da versão v0.27.0 , o k6 não tinha suporte suficiente para gerar solicitações a uma taxa constante. Portanto, implementamos uma solução alternativa em JavaScript , calculando o tempo que leva para concluir as solicitações de cada iteração do script. Com a v0.27.0, isso não é mais necessário.
Neste artigo, discuti como k6 pode atingir uma taxa de solicitação consistente com a nova API de script usando
constant-arrival-rate
artista. Este executor simplifica o código e fornece os meios para atingir um número fixo de solicitações por segundo. Isso contrasta com uma versão anterior do mesmo artigo, na qual descrevi outro método para obter substancialmente os mesmos resultados calculando o número de usuários virtuais, iterações e duração usando uma fórmula e algum código JavaScript clichê. Felizmente, essa nova abordagem funciona conforme o esperado e não precisamos mais usar nenhum hacks.
Eu espero que você tenha gostado de ler este artigo. Eu adoraria ouvir sua opinião.
