Skip to content

Commit

Permalink
Merge pull request #224 from Xceptance/updates_RN79
Browse files Browse the repository at this point in the history
doc updates for XTC79
  • Loading branch information
js-xc authored Mar 1, 2024
2 parents 83f77e1 + 47ff184 commit ccac534
Show file tree
Hide file tree
Showing 4 changed files with 30 additions and 28 deletions.
33 changes: 10 additions & 23 deletions content/en/xtc/integrations/500-api.md
Original file line number Diff line number Diff line change
Expand Up @@ -75,29 +75,7 @@ curl -X GET \

If all went well, you should see a JSON response with all your load tests printed to the console.

For your convenience, here is a list of current API endpoints and what they are used for:

### Project API Endpoints

* Retrieve the details of a project:<br />
`GET /public/api/v1/orgs/<org-short-name>/projects/<project-short-name>` (requires scope `PROJECT_DETAILS`)
* List all the projects of an organization:<br />
`GET /public/api/v1/orgs/<org-short-name>/projects` (requires scope `PROJECT_LIST`)

### Load Test API Endpoints

* Copy the specified load test and run the copy:<br />
`GET /public/api/v1/orgs/<org-short-name>/projects/<project-short-name>/loadTests/<load-test-number>/runCopy` (requires scope `LOADTEST_COPY_RUN`)
* List the details of a certain load test:<br />
`GET /public/api/v1/orgs/<org-short-name>/projects/<project-short-name>/loadTests/<load-test-number>` (requires scope `LOADTEST_DETAILS`)
* List all load tests in a project:<br />
`GET /public/api/v1/orgs/<org-short-name>/projects/<project-short-name>/loadTests`(requires scope `LOADTEST_LIST`)
* Download the specified report archive:<br />
`GET /public/api/v1/orgs/<org-short-name>/projects/<project-short-name>/loadTests/<load-test-number>/reports/<report-number>/download`(requires scope `LOADTEST_REPORT_DOWNLOAD`)
* Download the specified result archive:<br />
`GET /public/api/v1/orgs/<org-short-name>/projects/<project-short-name>/loadTests/<load-test-number>/results/<result-number>/download`(requires scope `LOADTEST_RESULT_DOWNLOAD`)
* List the status of a certain load test:<br />
`GET /public/api/v1/orgs/<org-short-name>/projects/<project-short-name>/loadTests/<load-test-number>/status`(requires scope `LOADTEST_STATUS`)
For a complete list of current API endpoints, their purpose and how they are used, please use the API Explorer:

## API Documentation and Explorer

Expand All @@ -115,3 +93,12 @@ You can also try API calls directly from the API Explorer. For this to work, you
Handling authentication in the API explorer: an access token has been created for the entered client ID and secret.
{{< /image >}}

## API Versions

The XTC API is versioned. The latest stable API version will be marked accordingly in the API Explorer. In addition to this, an API version can be marked as _Preview_ to indicate that the version is not yet stable. This means that endpoints may be added or deleted, and the format of URLs, as well as the amount and type of incoming and outgoing data, may change without notice.

To switch between API versions in the API Explorer, select the desired version from the drop-down list in the upper right corner.

{{< image src="xtc/api_explorer_versions.png" >}}
The API version switch.
{{< /image >}}
15 changes: 15 additions & 0 deletions content/en/xtc/loadtesting/120-load-project-configuration.md
Original file line number Diff line number Diff line change
Expand Up @@ -71,3 +71,18 @@ When editing an existing secret property in the UI, its current value will be sh

Properties configured at project level apply to all new load tests alike, while [properties defined at a certain load test]({{< relref "155-lt-settings" >}}) apply to that load test only. Load-test-level properties will overwrite project-level properties. Properties that are not set in XTC will be read from the project data.

## Environment

Load tests are executed with XLT, Xceptance’s tool to drive load and performance tests. XLT is developed independently from XTC. New releases may come with improvements and also new features. New features may introduce incompatible changes, so from time to time we will need to release a new major version of XLT.

Incompatible changes in XLT may break your existing load test suites so XTC lets you choose between the previous and the new XLT execution environment. However, this choice is available for a limited time only.

The XLT support and deprecation policy is as follows: whenever a new major version of XLT is available, **the previous major version** is marked as deprecated, but **remains available for another 8 weeks**. This means while you can continue your current load testing activities uninterrupted, you should also plan and perform the migration of your test suite to the new XLT version in time. **After the migration period of 8 weeks, the previous XLT version will be removed** and the new version will be the only one available.

XTC helps to manage that transition. Project admins can define in the project settings which version of XLT should be the default one. Go to _Project > Configuration > Execution > Execution Environment_ and choose an XLT version. You will want to adjust this setting when you start a new project or when you are done migrating your test suite. The default version will be effective when creating a new load test, but not when duplicating an existing one.

Testers may override this default for a particular load test in the settings of that load test. Open _Load Test > Settings > Common Machine Configuration_ and choose the wanted version of the execution environment. Use this to test your migrated code (probably on another Git repository branch) with the new version, before switching to this version in general.

{{% note title="What about minor version changes?" %}}
Minor changes, such as 6.0.1 or 6.1.0, are backward-compatible. This means two things: first, there is nothing for you to do. Second, XTC may be updated with a new minor XLT version without prior notice. However, we will always list the current version in our release notes.
{{% /note %}}
10 changes: 5 additions & 5 deletions content/en/xtc/loadtesting/155-lt-settings.md
Original file line number Diff line number Diff line change
Expand Up @@ -33,17 +33,17 @@ Learn more in our _Load Testing_ section about [configuring load profiles]({{< r

The most important (and mandatory) part of the test setup is the configuration of the test machines to be used.

In _Common Machine Configuration_ you can enter a password for the communication between the master and all agent machines (a random password will be generated by default).
In ***Common Machine Configuration*** you can enter a password for the communication between the master and all agent machines (a random password will be generated by default). You can also [override the default XLT execution environment version]({{< relref "120-load-project-configuration/#environment" >}}) in this section.

The machines to be used can be entered in _Google Machines_ or _Custom Machines_ (or you use a combination of both).
The machines to be used can be selected from _Amazon Cloud Machines_, _Google Cloud Machines_, _Hetzner Cloud Machines_ or _Custom Machines_ (or you use a combination of these).

If you want to use machines in the **Google Cloud**, you just enter configuration details and the selected machines will automatically be started prior to the load test and terminated afterwards by XTC. To edit the Google Cloud machine configuration, click the editing button next to the _Google Machines_ headline. There you can
If you want to use machines in the ***Amazon/Google/Hetzner Cloud***, you just enter configuration details and the selected machines will automatically be started prior to the load test and terminated afterwards by XTC. To edit the cloud machine configuration, click the editing button next to the headline. There you can
* specify which _regions_ the machines should run in (you can pick several, the machines will be spread over the selected regions as evenly as possible),
* pick an _instance template_ for your machines (currently tiny, small, medium or xlarge), depending on how much computing power you think you'll need,
* pick an _instance template_ for your machines, depending on how much computing power you think you'll need,
* select the number of machine instances to start (_instance count_), and
* select the number of _agents per instance_.

Instead of starting and terminating Google Machines per XTC, you can also use other machines for testing. You can define these in **Custom Machines**: just enter a list of host names and the agents per instance for your machines, and make sure these are running while the test is executed.
Instead of starting and terminating Cloud Machines per XTC, you can also use other machines for testing. You can define these in ***Custom Machines***_:_ just enter a list of host names and the agents per instance for your machines, and make sure these are running while the test is executed.

As **[test sizing]({{< relref "/xlt/load-testing/how-tos/test-sizing" >}})** is a whole topic in itself, you might want to check the CPU usage after your test and maybe adjust the number of machines for the next test run.

Expand Down
Binary file added static/images/xtc/api_explorer_versions.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

0 comments on commit ccac534

Please sign in to comment.