Giter Club home page Giter Club logo

openpaas-gatling's Introduction

Gatling OpenPaaS

This project enables to proceed to OpenPaaS load testing using Gatling technology.
It aims to provide building blocks, specific OpenPaaS APIs steps as well as more complex scenarios.

Configuration

The configuration is defined in the src/main/scala/com/linagora/openpaas/gatling/Configuration.scala file. However, all the parameters can be set through environment variables. Just copy the env.sh.tpl file as env.sh, update the values and source it: source env.sh

Available settings:

  • OpenPaaS platform admin credentials for domain provisioning
  • Domain used for load testing
  • Platform admin & Domain admin credentials
  • Base URL for OpenPaaS endpoints
  • Base URL for Sabre endpoints
  • Base URL for Web Socket server
  • Base URL for Jmap server
  • User count for scenario
  • Scenario duration
  • Inject duration
  • Number of contacts per virtual user
  • Number of calendar events per virtual user
  • Number of emails per virtual user
  • Authentication strategy
  • Base URL for LemonLDAP portal page
  • Base URL for CAS portal page

Environment variables:

  • OPENPAAS_HOSTNAME which is set to localhost by default
  • OPENPAAS_PORT which is set to 8080 by default
  • OPENPAAS_PORT_IN_URL which is set to false by default, if set to true the value of OPENPAAS_PORT will be appended to OPENPAAS_HOSTNAME when generating the url.
  • OPENPAAS_PROTOCOL which is set to http by default (you can use https instead for example)
  • SABRE_BASE_URL which is set to `` by default. If a url is provided, it will be used as the base URL for CalDAV requests, otherwise the ESN's DAV Proxy will handle CalDAV requests.
  • WEBSOCKET_HOSTNAME which is set to OPENPAAS_HOSTNAME by default
  • WEBSOCKET_PORT which is set to OPENPAAS_PORT by default
  • WEBSOCKET_PROTOCOL which is set to ws by default (you can use wss instead for example)
  • JMAP_HOSTNAME which is set to OPENPAAS_HOSTNAME by default
  • JMAP_PORT which is set to 1080 by default
  • JMAP_PROTOCOL which is set to OPENPAAS_PROTOCOL by default
  • INJECT_DURATION which is set to 10 by default. Unit is second
  • SCENARIO_DURATION which is set to 10 by default. Unit is second
  • USER_COUNT which is set to 1 by default
  • HUMAN_ACTION_MIN_DELAY which is set to 7 by default. The minimum amount of seconds between 2 human actions.
  • HUMAN_ACTION_MAX_DELAY which is set to 15 by default. The maximum amount of seconds between 2 human actions.
  • AUTHENTICATION_STRATEGY which is set to basic by default (you can use lemonldap, oidc, pkce, pkce_with_cas instead)
  • OIDC_CLIENT oidc client to use for oidc and pkce authentication strategies
  • OIDC_CALLBACK url to redirect to after a successful login with oidc and pkce authentication strategies. Make sure to add redirect URL with explicit port in the lemonLDAP manager
  • LEMONLDAP_PORTAL_HOSTNAME which is set to auth.latest.integration-open-paas.org by default.
  • CAS_HOSTNAME which is set to OPENPAAS_HOSTNAME by default. used with pkce_with_cas authentication strategy.
  • CAS_PORT which is set to 443 by default
  • CAS_PROTOCOL which is set to https by default
  • CAS_PORT_IN_URL which is set to false by default, if set to true the value of CAS_PORT will be appended to CAS_HOSTNAME when generating the url.
  • PLATFORM_ADMIN_USER is the user name of the platform administrator.
  • PLATFORM_ADMIN_PWD is the password of the platform administrator.
  • INBOX_SPA_PATH is the path to access the Inbox SPA. which is set to inbox by default
  • CALENDAR_SPA_PATH is the path to access the Calendar SPA, which is set to calendar by default
  • CONTACTS_SPA_PATH is the path to access the Contacts SPA, which is set to contacts by default
  • KEYCLOAK_PORTAL_PROTOCOL which is set to OPENPAAS_PROTOCOL by default
  • KEYCLOAK_PORTAL_HOSTNAME which is set to auth.latest.integration-open-paas.org by default
  • KEYCLOAK_REALM which is set to openpaas by default
  • LOAD_STATIC_ASSETS which is set to false by default, if set to true the simulation will load static assets delivered by nginx

For example, to run with OpenPaaS port 8000:

$ export OPENPAAS_PORT="8000"
$ sbt
  > gatling:test

User pool

There are two ways of creating a user pool for running tests:

  1. Using a src/test/resources/users.csv file containing credentials of users. This is the default method to retrieve user credentials. It is expected to have all users provisioned in the testing platform.

  2. Including the provisioning steps in each scenario. This method requires platform admin credentials in configuration.

Running tests in LemonLDAP integrated platform

For OpenPaaS instances that are protected by LemonLDAP, you need to provide the LemonLDAP portal page url in the configuration. You also have to change the AUTHENTICATION_STRATEGY configuration to lemonldap. Plus, all users credentials must be stored in src/test/resources/users.csv file.

Gatling Recorder

The Gatling Recorder helps you to quickly generate scenarios, by either acting as a HTTP proxy between the browser and the HTTP server or converting HAR (Http ARchive) files. Either way, the Recorder generates a simple simulation that mimics your recorded navigation.

All the instructions to install and use are available at this documentation

Run scenario

You can run all the scenario via sbt:

$ sbt
 > gatling:test

Run a specific scenario via sbt:

$ sbt
 > gatling:testOnly SCENARIO_FQDN

For example, you can run this scenario to open Calendar and open an event to view it details:

$ sbt
> gatling:testOnly com.linagora.openpaas.gatling.calendar.ViewEventDetailsSimulation

Scenarios for Inbox

Send an email

Scenario

In this scenario, each user will:

  • Login to OpenPaaS
  • Go to Inbox
  • Open a composer window
  • Write an email, attach a 200kB file
  • Send the email
  • Log out

Run

$ sbt
> gatling:testOnly com.linagora.openpaas.gatling.unifiedinbox.SendEmailSimulation

Scenarios for Calendar

1. List calendars

Scenario

In this scenario, each user will:

  • Login to OpenPaaS
  • Go to Calendar, and all the usable calendars are listed

The equivalent simulation will ramp USER_COUNT users over INJECT_DURATION.

Run

$ sbt
> gatling:testOnly com.linagora.openpaas.gatling.calendar.ListCalendarsSimulation

2. Create a new calendar

In this scenario, each user will:

  • Login to OpenPaaS
  • Go to Calendar
  • Create a new calendar

The equivalent simulation will ramp USER_COUNT users over INJECT_DURATION.

Run

$ sbt
> gatling:testOnly com.linagora.openpaas.gatling.calendar.CreateCalendarSimulation

3. View a calendar's details and update the calendar

In this scenario, each user will:

  • Login to OpenPaaS
  • Go to Calendar
  • Choose a calendar to view its details
  • Update the calendar

The equivalent simulation will ramp USER_COUNT users over INJECT_DURATION.

Run

$ sbt
> gatling:testOnly com.linagora.openpaas.gatling.calendar.ViewAndUpdateCalendarSimulation

4. View a calendar's details and then delete the calendar

In this scenario, each user will:

  • Login to OpenPaaS
  • Go to Calendar
  • Choose a calendar to view its details
  • Delete the calendar

The equivalent simulation will ramp USER_COUNT users over INJECT_DURATION.

Run

$ sbt
> gatling:testOnly com.linagora.openpaas.gatling.calendar.ViewAndDeleteCalendarSimulation

5. Create a new event

In this scenario, each user will:

  • Login to OpenPaaS
  • Go to Calendar
  • Create a new event in the default calendar

The equivalent simulation will ramp USER_COUNT users over INJECT_DURATION.

Run

$ sbt
> gatling:testOnly com.linagora.openpaas.gatling.calendar.CreateEventSimulation

6. Create a new event with a lot of attendees

In this scenario, each user will:

  • Login to OpenPaaS
  • Go to Calendar
  • Create a new event in the default calendar with a lof of attendees (between 100 and 200 attendees)

The equivalent simulation will ramp 20 users over 1 second. These numbers are configurable (see the commands below).

Run

  • Run with the default configuration (ramping 20 users over 1 second):
$ sbt
> gatling:testOnly com.linagora.openpaas.gatling.calendar.CreateEventWithLotsOfAttendeesSimulation
  • Run with a custom configuration (ramping 40 users over 2 seconds):
$ sbt
> ;-DrampUserCount=40;-DrampUserDuration=2;gatling:testOnly com.linagora.openpaas.gatling.calendar.CreateEventWithLotsOfAttendeesSimulation

7. Open an event

In this scenario, each user will:

  • Login to OpenPaaS
  • Go to Calendar
  • Open an event to view its details

The equivalent simulation will ramp USER_COUNT users over INJECT_DURATION.

Run

$ sbt
> gatling:testOnly com.linagora.openpaas.gatling.calendar.ViewEventDetailsSimulation

8. Open an event and update the event

In this scenario, each user will:

  • Login to OpenPaaS
  • Go to Calendar
  • Open an event to view its details
  • Update the event

The equivalent simulation will ramp USER_COUNT users over INJECT_DURATION.

Run

$ sbt
> gatling:testOnly com.linagora.openpaas.gatling.calendar.ViewAndUpdateEventSimulation

9. Open an event and delete the event

In this scenario, each user will:

  • Login to OpenPaaS
  • Go to Calendar
  • Open an event to view its details
  • Delete the event

The equivalent simulation will ramp USER_COUNT users over INJECT_DURATION.

Run

$ sbt
> gatling:testOnly com.linagora.openpaas.gatling.calendar.ViewAndDeleteEventSimulation

10. Mixed scenario

In this scenario, each user will:

  • Login to OpenPaaS
  • Go to Calendar
  • Do one of the following actions at random:
    • 40%: Open an event
    • 20%: Create an event with a few attendees (between 1 and 10 attendees)
    • 15%: Open an event and update the event
    • 10%: Create a new event
    • 5%: Open an event and delete the event
    • 5%: Open an event and update the event
    • 3%: Create a new calendar
    • 2%: View a calendar's details and then delete the calendar

The equivalent simulation will ramp USER_COUNT users over INJECT_DURATION.

Run

$ sbt
> gatling:testOnly com.linagora.openpaas.gatling.calendar.CalendarMixSimulation

Scenarios for Contacts

Open a contact in the default address book

Scenario

In this scenario, each user will:

  • Login to OpenPaaS
  • Go to Contacts
  • Open the default address book
  • Open a contact
  • Log out

The equivalent simulation will ramp USER_COUNT users over INJECT_DURATION.

Run

$ sbt
> gatling:testOnly com.linagora.openpaas.gatling.addressbook.OpenContactInCollectedAddressBookSimulation

Platform Test Simulations

Calendar & Contacts

In this simulation, each user will:

  • Execute one of the following scenarios randomly:
    • Scenario 1 (80% chance): Calendar's mixed scenario
    • Scenario 2 (20% chance): Open a contact in the default address book
  • Pause between 5 and 10 seconds between scenarios
  • Number of users: USER_COUNT
  • Injection duration: INJECT_DURATION
  • Scenario duration: SCENARIO_DURATION
$ sbt
> gatling:testOnly com.linagora.openpaas.gatling.CalendarAndContactsWithRefreshTokenSimulation

Inbox

In this simulation, each user will:

  • Login
  • Execute one of these actions randomly:
    • 5%: send email
    • 10%: open mailbox
    • 15%: read email
    • 70%: idle
  • Pause 60 seconds between each case (it's the time for the idle sync to happen)

The equivalent simulation will ramp USER_COUNT users over INJECT_DURATION with SCENARIO_DURATION as the scenario duration for a user.

$ sbt
> gatling:testOnly com.linagora.openpaas.gatling.InboxPlatformSimulation

openpaas-gatling's People

Contributors

arsnael avatar chibenwa avatar michaelbailly avatar remk avatar renaudboyer avatar rockymeadow avatar rouazana avatar vincent-zurczak avatar

Stargazers

avatar

Watchers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Forkers

remk rouazana itswillta tanandy michaelbailly arsnael rezk2ll

openpaas-gatling's Issues

Add a platform test simulation for Calendar & Contacts

Context: To validate the OpenPaaS platform, we will run 2 platform test simulations separately for:

  • Calendar & Contacts
  • Inbox

In the scope of this issue, the platform test simulation for Calendar & Contacts needs to be added.

Update test scenarios for Contacts

Users and contacts need to be provisioned first before running the performance tests. If you want to do some user provisioning but not having a tool yet, you can do it with the help of https://github.com/huy-ta/openpaas-provisioning.

To-dos

  • Provide a simulation to provision contacts
  • Refactor the old tests
  • Need to load static assets before doing anything
  • Instructions to run the performance tests (a.k.a. update README.md)

PRs:

Definition of Done

For each of the problem above, make sure:

  • The PR(s) are reviewed & merged to the main branch.
  • The documentation is updated accordingly (README.md).
  • The tests run without any problem in the main branch on the load testing platform with 1 user. Fix any problems that arise.
  • The real tests are launched.

Update test scenarios for Calendar

Users and events need to be provisioned first before running the performance tests. If you want to do some user provisioning but not having a tool yet, you can do it with the help of https://github.com/huy-ta/openpaas-provisioning.

To-dos

  • Refactor event search test(s)
  • Add Calendar CRUD tests
  • Add Event CRUD tests (with no attendees)
  • Add test cases for event CRUD with (lots of) attendees
  • Add Calendar Mix Scenario
  • Use Gatling simulations to provision events & calendars
  • Stress the People API => Add this to the Create & Update Event scenarios
  • Need to load static assets before doing anything
  • Add test cases for recurrent events
  • The endpoints need to be changed once the web frontend makes direct requests to Sabre
  • Integration with OIDC
  • Instructions to run the performance tests (a.k.a. update README.md)

PRs:

Definition of Done

For each of the problem above, make sure:

  • The PR(s) are reviewed & merged to the main branch.
  • The documentation is updated accordingly (README.md).
  • The tests run without any problem in the main branch on the load testing platform with 1 user. Fix any problems that arise.
  • The real tests are launched.

Provide a way to load the "main.js" file

Currently, the main.js file has different a name every time we build each SPA because Webpack inserts a random hash to the file in production mode. We need to find a way to extract the main.js from within the index.html file, and then load it.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.