aboutsummaryrefslogtreecommitdiffhomepage
path: root/site/dev/testing/ct.md
diff options
context:
space:
mode:
Diffstat (limited to 'site/dev/testing/ct.md')
-rw-r--r--site/dev/testing/ct.md24
1 files changed, 14 insertions, 10 deletions
diff --git a/site/dev/testing/ct.md b/site/dev/testing/ct.md
index 63095ab108..cba6f7bc91 100644
--- a/site/dev/testing/ct.md
+++ b/site/dev/testing/ct.md
@@ -17,6 +17,7 @@ Overview
Cluster Telemetry allows you to run [telemetry](https://www.chromium.org/developers/telemetry)'s benchmarks, lua scripts and other tasks using multiple repository patches through Alexa's [top 1 million](http://s3.amazonaws.com/alexa-static/top-1m.csv.zip) web pages.
Developers can use the framework to measure the performance of their patch against the top subset of the internet on both Desktop and Android.
+tl;dr documentation is [here](https://www.chromium.org/developers/cluster-telemetry).
SKP files are a binary format for the draw commands Chromium sends to Skia for rasterization. The goal of the project started off with wanting to collect a large repository of 10k SKP files. This repository, after incremental changes in approaches, has since grown to ~910k and now supports running all telemetry benchmarks. The top level feature request of this project was [skia:1268](https://bug.skia.org/1268).
@@ -24,17 +25,20 @@ A web application has been created on Google Compute Engine that automates the p
The framework also contains the ability to run lua scripts on the SKP repository to scrape web pages. It only takes a few minutes to run a lua scraping script on ~910k SKP files.
-Most users will use these two features:
+Most users will use these three features:
-* Chromium Perf. Documentation [here](https://www.chromium.org/developers/cluster-telemetry). Webpage [here](https://ct.skia.org/chromium_perf/).
-* Run Lua Scripts. Documentation about lua bindings is [here](https://skia.org/user/special/lua). Webpage [here](https://ct.skia.org/lua_script/).
+* Chromium Perf. Documentation [here](https://docs.google.com/document/d/1GhqosQcwsy6F-eBAmFn_ITDF7_Iv_rY9FhCKwAnk9qQ/). Webpage [here](https://ct.skia.org/chromium_perf/).
+* Chromium Analysis. Documentation [here](https://docs.google.com/document/d/1ziof4lNwDFXyerVbEocdF3_DdUHVnD3FKYB9rShztuE/). Webpage [here](https://ct.skia.org/chromium_analysis/).
+* Run Lua Scripts on SKP repositories. Documentation about lua bindings is [here](https://skia.org/user/special/lua). Webpage [here](https://ct.skia.org/lua_script/).
+
+Note: The top 1M web pages includes potentially offensive content. Please use caution when visiting page links from the framework.
<a name="framework_usage"></a>
Framework Usage
---------------
-The Chromium Perf tryserver in CT has been used to gather perf data over the top 10k web pages for the following Chromium projects:
+The Chromium Perf page in CT has been used to gather perf data over the top 10k web pages for the following Chromium projects:
* Slimming paint
* Performance data for layer squashing and compositing overlap map
@@ -75,17 +79,17 @@ System Architecture
<a name="detailed_explanation"></a>
### Detailed explanation of steps
-1. User submits a Lua script task, a Performance task, or an Admin task (rebuild chrome, recreate pagesets, recreate webpage archives, capture SKPs) using the GCE web application [here](http://ct.skia.org).
+1. User submits a Lua script task, a Performance task, an Analysis task, or an Admin task (build chrome, recreate pagesets, recreate webpage archives, capture SKPs) using the GCE web application [here](http://ct.skia.org).
-2. Each task is exposed by the web application in JSON. The CT master polls the web application and picks up new tasks.
+2. Each task is exposed by the web application in JSON. The CT master polls the web application and picks up new tasks. It has the ability to run tasks in parallel.
-3. The master pushes new tasks to all the workers using the master scripts [here](https://skia.googlesource.com/buildbot/+/master/ct/go/master_scripts/). The master scripts then check to see when the workers are done with the requested task.
+3. The master triggers swarming tasks using the master scripts [here](https://skia.googlesource.com/buildbot/+/master/ct/go/master_scripts/). The master scripts then check to see when the tasks are done.
-4. The workers execute the task using the worker scripts [here](https://skia.googlesource.com/buildbot/+/master/ct/go/worker_scripts/). All generated artifacts (CSV files, logs, SKP files, archives, etc) are then stored locally and copied to Google Storage. Worker logs are available [here](https://uberchromegw.corp.google.com/i/skia-ct-master/all_logs).
+4. Swarming bots in the CT pool execute the task using the worker scripts [here](https://skia.googlesource.com/buildbot/+/master/ct/go/worker_scripts/). All generated artifacts (CSV files, logs, SKP files, archives, etc) are then copied to Google Storage.
-5. The master scripts periodically check the workers to see when they are done with the requested task. Once the workers are done the generated artifacts are then read from Google Storage and consolidated (if required).
+5. Once swarming tasks complete, master scripts read the generated artifacts from Google Storage and consolidate them (if required).
-6. The master scripts then email results of the task to the user who requested it. The master scripts also update the status of the task to completed on App Engine.
+6. The master scripts then email results of the task to the user who requested it. The scripts also update the status of the task to completed on the web application.
<a name="code"></a>