Testing single sign on (google)

Grafana k6 Community Lounge
1

Hello, i need some advice about 2 question :

  1. how to testing a system who use google sign on ?
  2. when users ask about “how much concurent user can handled by the system”, what type of executor must i use?

ref : Executors

thanks guys

2

Hi there, welcome to the forum :slight_smile:

  1. Do you mean Google’s OAuth 2.0 authentication? Take a look at this thread for how to approach this.

  2. That’s up to you to decide depending on how you want to define your test. Take a look at the “When to use” section for each executor for an idea of good use cases. If you want to be able to adjust the amount of VUs over time then the ramping-vus executor might be a good fit. Note that this is the same executor used for the simpler stages configuration, so you might not need the more advanced Scenarios functionality.

Also take a look at the test types documentation. In your case you’re looking for a load and eventually stress test.

3

hi @imiric , thanks for your advice.

but i’m still confused, when i create simple stage, example :
stages: [
{ duration: “1m”, target: 50 },
{ duration: “3m”, target: 50 },
{ duration: “1m”, target: 0 },
],

and i have an endpoint : mysite.com/credentials

i see on k6 dashboard, my vus : 50 and mysite.com/credentials hited 100 request.

so, how can i explain user about concurrent users? the real concurrent users 50 vus or 100 request?

4

If the test finished successfully, without any errors, failed checks and with acceptable response times (whatever your definition of “acceptable” is), then you can say that your system supports 50 concurrent users.

The point of load/stress testing though is to determine the maximum amount of users your system can support with no errors and performance degradation. So if you feel that 50 concurrent users is enough, that’s OK, but you can start increasing that number until you notice failures.

The number of requests, usually measured within a time period (e.g. requests per second, RPS) is another metric you can track, but that’s distinct from the number of users. You can also choose to optimize for this, in which case the ramping-arrival-rate executor might be useful.