You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/waiting-room/additional-options/test-waiting-room.md
+63-97Lines changed: 63 additions & 97 deletions
Original file line number
Diff line number
Diff line change
@@ -6,9 +6,9 @@ weight: 9
6
6
7
7
# Test a waiting room
8
8
9
-
Follow this tutorial to ensure your waiting room queues and admits users as expected.
9
+
Follow this tutorial to test your waiting room behavior in response to load. To accurately simulate traffic through your waiting room with a load test, run your test script or planner for a period of time longer than a minute, ideally more than 2-3 minutes. You can run a load test using a variety of tools including [loader.io](http://loader.io), [jmeter](http://jmeter.apache.org), and [postman.com](http://postman.com). You can also write a plain shell script to simulate user requests (each representing a distinct user).
10
10
11
-
{{<Asidetype="warning"header="Warning:">}}
11
+
{{<Asidetype="warning"header="Warning">}}
12
12
This tutorial uses an open-sourced load testing tool that is not created or supported by Cloudflare.
13
13
{{</Aside>}}
14
14
@@ -18,126 +18,92 @@ This tutorial uses an open-sourced load testing tool that is not created or supp
18
18
19
19
Before you start this tutorial, ensure you have:
20
20
21
-
- Fulfilled all the [prerequisites](/waiting-room/#prerequisites)
22
-
- Previously [created a waiting room](/waiting-room/get-started/)
23
-
- Updated the [sample script](#1-download-sample-script) to ensure your waiting room captures when a "simulated user" enters and is released from your waiting room (if you [customized the design](/waiting-room/how-to/customize-waiting-room/) of your waiting room)
21
+
- All the [prerequisites](/waiting-room/#prerequisites) completed.
22
+
- For this tutorial, we will use an open source tool from Apache, [JMeter](https://jmeter.apache.org/). You can download the binary from [JMeter's website](https://jmeter.apache.org/download_jmeter.cgi).
24
23
25
24
---
26
25
27
26
## 1. Download sample script
28
27
29
-
First, download the [sample script](https://github.com/kcantrel/test-cf-waitingroom/blob/master/simulate_requests) from GitHub.
28
+
First, download the [sample](https://github.com/yj7o5/cf-waiting-room-testing/blob/main/plan.jmx) JMeter plan (configuration file) from GitHub.
30
29
31
-
This script simulates users entering a waiting room. It divides traffic into two phases (`Phase 1`and `Phase 2`) so you can test wait times as load increases and then decreases.
30
+
This sample plan simulates 200 active users visiting the site, slowly ramping up traffic within the first minute and then maintaining 200 active users for the next three minutes. The test plan for this tutorial follows the setup outlined in the next steps.
32
31
33
-
## 2. Run sample script
32
+
## 2. Run sample plan
34
33
35
-
Once you have downloaded the script, run it with the following command-line arguments:
34
+
To run our test plan select the **play** button to get the test started. This should take roughly around 3-4 minutes.
36
35
37
-
-`-n <num_secs_p1>`: Number of seconds to send requests during phase 1
38
-
-`-m <num_secs_p2>`: Number of seconds to send requests during phase 2, which is fixed at 1 request per second
39
-
-`-s <sleep_time_p1>`: Amount of time to sleep between requests during phase 1 (fractional time accepted, such as `.3`)
40
-
-`-o <results>`: File to store the per-session statistics
41
-
-`URL`: Endpoint protected by a Cloudflare Waiting Room
Per the plan above, each [Thread Group](https://jmeter.apache.org/usermanual/test_plan.html#thread_group) performs the above action once. The user traffic ramps up within the first minute and keeps a sustained traffic for the next three minutes before users leave the site. You can send more or less traffic than what is being sent in this example by updating these properties.
As the script runs, it will output characters with each character representing:
70
-
71
-
- A user session that advanced past the waiting room
72
-
- The amount of time the user spent in the waiting room:
73
-
- 0 seconds: `.`
74
-
- 10 seconds: `a`
75
-
- 20 seconds: `b`
76
-
- 30 seconds: `c`<br/>
77
-
...
78
-
- 260 seconds: `A`
79
-
- 270 seconds: `B`<br/>
80
-
...
81
-
- 530 seconds: `0`
82
-
- 540 seconds: `1`<br/>
83
-
...
84
-
- Greater than 620 seconds: `!`
55
+
To analyze the results of your test, you can query Waiting Room Analytics (Beta) via Cloudflare’s GraphQL API to check Total Active Users and Queued Users for each minute of your load test.
85
56
86
-
## 3. Analyze results
87
57
88
-
Once the script finishes running, it creates a CSV file with the following fields:
89
58
90
59
<details>
91
-
<summary>Fields in CSV file</summary>
60
+
<summary>Example Curl Statement</summary>
92
61
<div>
93
-
<ul>
94
-
<li>
95
-
<strong>job</strong>: The fixed string will either be <strong>main</strong> for phase 1 or
96
-
<strong>post</strong> for phase 2
97
-
</li>
98
-
<li>
99
-
<strong>status</strong>: Status of the last response of the session:
100
-
</li>
101
-
<ul>
102
-
<li>
103
-
0: curl command received an HTTP status code of <code>200</code>
104
-
</li>
105
-
<li>
106
-
1: curl command did not receive any HTTP status codes, which typically means the curl
107
-
command itself failed
108
-
</li>
109
-
<li>
110
-
2: curl command received an HTTP status code of something other than <code>200</code>
111
-
</li>
112
-
</ul>
113
-
<li>
114
-
<strong>wait_time</strong>: Number of seconds the user waited in the waiting room
115
-
</li>
116
-
<li>
117
-
<strong>wr_cnt_before</strong>: Number of users in the waiting room when the session first
118
-
started
119
-
</li>
120
-
<li>
121
-
<strong>wr_cnt_after</strong>: Number of users in the waiting room when the session made it
122
-
past the waiting room
123
-
</li>
124
-
<li>
125
-
<strong>start_time</strong>: Time when the session first started (in UNIX epoch seconds)
126
-
</li>
127
-
<li>
128
-
<strong>end_time</strong>: Time when the session made it past the waiting room (in UNIX
To visualize your results, open your CSV file within a spreadsheet application. For example, here is a basic chart that shows the amount of time a user waited verses the time they first tried to get to the web service:
82
+
From our test, we see the following results (these are extracted from results of the query for readability):
83
+
84
+
- 15:35:00 UTC
85
+
-`"totalActiveUsers": 137,`
86
+
-`"totalActiveUsersConfig": 300,`
87
+
-`"totalQueuedUsers": 0`
88
+
89
+
- 15:36:00 UTC
90
+
-`"totalActiveUsers": 200,`
91
+
-`"totalActiveUsersConfig": 300,`
92
+
-`"totalQueuedUsers": 0`
93
+
94
+
- 15:37:00 UTC
95
+
-`"totalActiveUsers": 200,`
96
+
-`"totalActiveUsersConfig": 300,`
97
+
-`"totalQueuedUsers": 0`
136
98
137
-
99
+
- 15:38:00 UTC
100
+
-`"totalActiveUsers": 200,`
101
+
-`"totalActiveUsersConfig": 300,`
102
+
-`"totalQueuedUsers": 0`
138
103
139
-
In this example, you can clearly see when the script entered the second phase — with a reduced rate of new users per second — leading to decreased wait times.
104
+
The first minute mark, 15:35:00 UTC, shows 137 active users past the waiting room. This is because our traffic was set to gradually ramp up within the first minute and the test did not start exactly at the minute mark. When data was aggregated for the following minute, 15:36:00 UTC, the waiting room reported the total 200 users active we expected on the site as each “user” made subrequests. The active user count remained stable at 200 as long as it received subrequests from the traffic sent by the load test.
140
105
141
-
## 4. Adjust waiting room (optional)
106
+
{{<Asidetype="note"header="Note">}}
142
107
143
-
Based on the results of your test, you may want to adjust [the settings](/waiting-room/reference/configuration-settings/) of your waiting room.
108
+
Obtain your API token from the dashboard. Make sure your API token grants access to the **Analytics** resource. For more information on how to get the API token, follow the [Configure Analytics API token](/analytics/graphql-api/getting-started/authentication/api-token-auth/) guide.
0 commit comments