A request generator sends requests; a real browser also loads scripts, images, fonts and third-party tags, and calls your APIs the way the front end does. Traffic Generator puts that kind of load on your site at the volume and in the hours you choose, so you can watch the server, the CDN and the database before real visitors arrive.
Point load only at sites you own or are authorized in writing to test. The Terms of service forbid using YOOtraffic to overload a third-party site.
A request generator measures how fast the server answers a URL. A browser session also downloads every asset, runs the page's JavaScript, triggers the API calls the front end makes and fires each third-party tag, so it tests cache rules, the CDN and the scripts as well as the origin.
That makes it a good check of a new release, a move to a new host or CDN, or a template that added heavy scripts, with the device and browser mix your visitors actually use.
Traffic Generator sets how many sessions arrive in a day and in which hours, not an exact requests-per-second ramp. For a stress test to the breaking point or a precise concurrency curve, use a protocol tool such as k6, JMeter or Locust next to it.
A workable split: the protocol tool finds the ceiling of each endpoint, and the browser sessions show how the full page holds up at the traffic you actually expect.
Run load only against a site you own or have written permission to test, and check whether your hosting provider asks for notice before a load test. The Terms of service forbid using the service to overload any third-party site.
Start well below the level you are worried about and raise it between runs, so a problem shows up as a trend in your graphs rather than as an outage.
A store is moving to a new host before a seasonal sale and wants to see how the new setup handles a busy evening. The rehearsal runs a compressed version of that evening against the new host, with the store's own monitoring open.
| Target URL | The home page on the new host, with paths through category and product pages |
|---|---|
| Volume and schedule | 2,000 sessions concentrated in 2 hours, about 17 new sessions a minute |
| Session duration | 180 to 300 seconds |
| Page depth | 4 pages per session, about 8,000 page loads in all |
| Devices | The mobile and desktop split your analytics shows for the store |
| Country | The country the sale is aimed at |
| Traffic source | Direct, so the run is easy to separate from campaigns in analytics |
Cost of the rehearsal: 2,000 sessions with a duration of 180 to 300 seconds are billed at $0.0024 each, the mean of the shortest and the longest session, so $4.80 for the run.
Note response times, error rate and resource use at normal traffic, for the same hours of the day, before the first run.
Run the first batch at a fraction of the target, read the graphs, then raise the volume for the next run. Change one thing between runs: the volume, the hours or the pages covered.
Keep the dashboards open while the run is on. A campaign can be paused at any moment, and paused time costs nothing.
Set each metric from the run against the baseline. Which one degrades first, and at what volume, is the result of the rehearsal.
Acceptable use, data handling and the limits that apply to every tool are in the Trust Center
The sessions come from Traffic Generator, billed per session at a rate set by the session duration you configure. The full rate table is on the pricing page.
Yes, as long as the browsers can reach it: the address has to be publicly reachable, and the sessions open it the way any visitor would. A staging copy with its own analytics property also keeps the run out of your production reports.
There is no daily cap: you set the volume per day and the hours it runs in. Begin well below the level you want to test and raise it between runs, so you can tell which volume produced which effect.
Yes. The sessions run your analytics tag like any page load, so they are counted. On production, keep a note of the date and hours of the run so the peak is not read as demand later.
They are the right tools for an endpoint's ceiling. Most protocol tools do not run the page's JavaScript or load its third-party tags, and the browser modes some of them offer need your own machines to run at volume. Browser sessions fill that gap at the traffic you expect.
Record a baseline, run a small batch against your own site and raise the volume between runs