TestEngineering/Services/TokenServerAndSyncLoadTesting: Difference between revisions

 
(424 intermediate revisions by 3 users not shown)
Line 1: Line 1:
* NOTE: We currently have two Verifier stacks in Stage (and probably Production):
** The standalone Browser_ID Verifier stack: See that Verifier sections below...
** A Tokenserver+Verifier stack: See the TokenServer sections below...
== Quick Verification Of Stage Deployments ==
* This is a quick sanity test of the environment before getting started on load tests.
* TokenServer+Verifier Stage environment:
From the browser: https://token.stage.mozaws.net
curl https://token.stage.mozaws.net
curl -I https://token.stage.mozaws.net
Use the simple "make test" command from an install of tokenserver on the localhost or AWS instance.
cd loadtest
make test SERVER_URL=https://token.stage.mozaws.net
Alternate method:
Use the test tool from here: https://github.com/edmoz/fxa-sync-client
Install and check all collection types for a known account in Stage:
bin/sync-cli.js -e EMAIL -p PASSWORD --env stage -t COLLECTION
    where -t is one of bookmarks,history,passwords,tabs,addons,prefs,forms
* Verifier Stage environment:
In the browser: https://verifier.stage.mozaws.net/
curl https://verifier.stage.mozaws.net
curl -I https://verifier.stage.mozaws.net
Use the simple "make test" command from an install of browserid-verifier on the localhost or AWS instance.
cd loadtest
make test SERVER_URL=https://verifier.stage.mozaws.net
* Sync Server Stage environment:
Install server-syncstorage to the local host or AWS instance (see below)
$ cd server-syncstorage
Quick test against the TokenServer
$ ./local/bin/python ./syncstorage/tests/functional/test_storage.py --use-token-server <Stage TokenServer>
Current example:
$ ./local/bin/python ./syncstorage/tests/functional/test_storage.py --use-token-server
    https://token.stage.mozaws.net/1.0/sync/1.5
Quick tests against the Sync nodes
$ ./local/bin/python ./syncstorage/tests/functional/test_storage.py <Stage Sync Node>#<Node Secret>
Current examples:
$ ./local/bin/python ./syncstorage/tests/functional/test_storage.py
    https://sync-1-us-east-1.stage.mozaws.net#<Node Secret>
$ ./local/bin/python ./syncstorage/tests/functional/test_storage.py
    https://sync-1-us-east-1.stage.mozaws.net#<Node Secret>
$ ./local/bin/python ./syncstorage/tests/functional/test_storage.py
    https://sync-1-us-east-1.stage.mozaws.net#<Node Secret>
Get the Node Secret information from OPs
* Using TPS
** The TPS FxA/Sync automated tests can be used as well, but the following file will have to be edited to add Stage environment configuration parameters: https://github.com/mozilla/gecko-dev/blob/master/testing/tps/tps/testrunner.py
** See the following wiki page for more information: https://wiki.mozilla.org/User_Services/Sync/Run_TPS
** See also: https://bugzilla.mozilla.org/show_bug.cgi?id=1006675
== Quick Verification Of Production Deployments ==
* This is a quick sanity test of the environment after a new deployment.
* Tokenserver+Verifier Production Environment
In the browser: https://token.services.mozilla.com
curl https://token.services.mozilla.com
curl -I https://token.services.mozilla.com
Then:
Use the test tool from here: https://github.com/edmoz/fxa-sync-client
Install and check all collection types for a known account in Production:
bin/sync-cli.js -e PROD-EMAIL -p PASSWORD -t COLLECTION
    where -t is one of bookmarks,history,passwords,tabs,addons,prefs,forms
* Verifier Production Environment
In the browser: https://verifier.accounts.firefox.com
curl https://verifier.accounts.firefox.com
curl -I https://verifier.accounts.firefox.com
Then:
Use the simple "make test" command from an install of browserid-verifier on the localhost or AWS instance.
cd loadtest
make test SERVER_URL=https://verifier.accounts.firefox.com
* Sync Server Stage environment
Sign in with a known FxA account and sync data with a current Production account (sync node).
Create a new FxA account and set up sync.
== Load Test Tool Client/Host ==
== Load Test Tool Client/Host ==
* It is always best to configure an AWS instance as the load test tool client/host.
* It is always best to configure an AWS instance as the host for all load testing.
* The actual Load Test broker and agents run in the Load Test environment set up by rfkelly. See the following wiki:
* All load tests can now run on the localhost (the AWS instance) or against the new Loads Cluster. See the following links for more information:
** https://wiki.mozilla.org/QA/Services/FxATestEnvironments#FxA_Load_Test_Environment
** https://wiki.mozilla.org/QA/Services/LoadsV1ClientTestHost
** https://wiki.mozilla.org/QA/Services/TSVerifierSyncTestEnvironments#Loads_Services_Cluster_Environment


=== Creating a RHEL AWS instance ===
== Installing BrowserID-Verifier and the Loads tool on Localhost or AWS ==
* Pick a Region then Create Instance > Launch Instance
* Installation:
* Follow the prompts to create a basic, RHEL-flavored instance
$ git clone git://github.com/mozilla/browserid-verifier
* Use of the QA/Dev key pairs that have been set up for this:
$ cd browserid-verifier
** US East Key Pair: QA-Dev-Share (created by jbonacci) for general use
Note: You may want to install a specific branch for testing vs defaulting to Master
** US West Key Pair: QA-dev-share (created by RaFromBRC) for general use
$ npm install
* Once the instance is running, log in as "ec2-user"
$ npm test
$ cd loadtest
$ make build
      Note: This should hit Stage by default: SERVER_URL=https://verifier.stage.mozaws.net


* The following apps, tools, and libs will need to be installed for use with various Services applications:
* Note: This will install a local copy of the Loads tool for use with the verifier.
** gcc, gcc-c++
** hg
** git
** python-devel
** automake, autoconf, and libtool  (required for libzmq, for easy_install)
** pip
** virtualenv
** node/npm
** zeromq 3.X
** gmp, gmp-devel


* Also, general rhel updates:
== Running the load test against the Verifier in Stage ==
  $ sudo yum -y update
* Stage environment:  
  and/or
  $ make test
  $ sudo yum -y upgrade
or
  $ make test SERVER_URL=https://verifier.stage.mozaws.net
$ make bench
or
  $ make bench SERVER_URL=https://verifier.stage.mozaws.net
Note: the current version of 'make bench' tends to use a lot of CPU and Memory on the localhost.   
The recommendation is to use 'make test' and 'make megabench' instead (see below)...
Note: The Stage Verifier hits the Stage mockmyid server


* Now, the instance should be ready for installing and using the Loads tool.
* Production environment:
$ make test SERVER_URL=https://verifier.accounts.firefox.com
$ make bench SERVER_URL=https://verifier.accounts.firefox.com


=== Creating an Ubuntu AWS instance ===
== Using the Loads V1 Services Cluster for the Verifier ==
* Pick a Region then Create Instance > Launch Instance
* By using the Loads Services Cluster, we can offload the broker/agents processes and save client-side CPU and memory.
* Follow the prompts to create a basic, Ubuntu-flavored instance
* Changes were made to Makefile and the load test to use the cluster and some associated config files (for test, bench, megabench).
* Use of the QA/Dev key pairs that have been set up for this:
* Stage environment:
** US East Key Pair: QA-Dev-Share (created by jbonacci) for general use
$ make megabench SERVER_URL=https://verifier.stage.mozaws.net
** US West Key Pair: QA-dev-share (created by RaFromBRC) for general use
* Once the instance is running, log in as "ubuntu"


* The following apps, tools, and libs will need to be installed for use with various Services applications:
* Dev environment:
** gcc, g++
$ make megabench SERVER_URL=TBD
** mercurial
** git
** python-setuptools, python-virtualenv, and python-dev
** automake, autoconf, libtool
** m4
** node/npm
** libzmq and zeromq 3.X
** gmp-5.1.3 or newer


* Also, general rhel updates:
* Production environment:
  $ sudo apt-get update
  $ make megabench SERVER_URL=https://verifier.accounts.firefox.com
and/or
$ sudo apt-get upgrade


* Now, the instance should be ready for installing and using the Loads tool.
* REFs:
** https://wiki.mozilla.org/QA/Services/LoadsToolsAndTesting1
** https://github.com/mozilla/browserid-verifier/tree/master/loadtest


== Installing the Loads tool on the AWS instance for TokenServer ==
== Installing TokenServer+Verifier and the Loads tool on Localhost or AWS ==
* Installation:
$ git clone https://github.com/mozilla-services/tokenserver
$ cd tokenserver
Note: You may want to install a specific branch for testing vs defaulting to Master
$ make build
$ make test
    Note: This is for local testing only
$ cd loadtest
$ make build
    Note: This should hit Prod by default: SERVER_URL=https://token.services.mozilla.com
 
* Note: This will install a local copy of the Loads tool for use with TokenServer+Verifier.
 
== Running the load test against TokenServer+Verifier in Stage ==
* Stage environment:
$ make test SERVER_URL=https://token.stage.mozaws.net
$ make bench SERVER_URL=https://token.stage.mozaws.net
Note: the current version of 'make bench' tends to use a lot of CPU and Memory on the localhost.   
The recommendation is to use 'make test' and 'make megabench' instead (see below)...
Note: This also hits the Stage Verifier, which in turns hits the Stage mockmyid server
 
* And while we are at it...
* Dev environment:
$ make test SERVER_URL=https://token.dev.lcip.org
$ make bench SERVER_URL=https://token.dev.lcip.org
 
* Production environment:
$ make test SERVER_URL=https://token.services.mozilla.com
$ make bench SERVER_URL=https://token.services.mozilla.com
 
== Using the Loads V1 Services Cluster for TokenServer+Verifier ==
* By using the Loads Services Cluster, we can offload the broker/agents processes and save client-side CPU and memory.
* Changes were made to Makefile and the load test to use the cluster and some associated config files (for test, bench, megabench).
* Stage environment:
$ make megabench SERVER_URL=https://token.stage.mozaws.net
 
* Dev environment:
$ make megabench SERVER_URL=https://token.dev.lcip.org
 
* Production environment:
$ make megabench SERVER_URL=https://token.services.mozilla.com
 
* REFs:
** https://wiki.mozilla.org/QA/Services/LoadsToolsAndTesting1
** https://github.com/mozilla-services/tokenserver/tree/master/loadtest
 
== Installing Sync and load testing on Localhost or AWS ==
  Installation:
  Installation:
  $ TBD
  $ git clone https://github.com/mozilla-services/syncstorage-loadtest/
$ cd syncstorage-loadtest
Note: You may want to install a specific branch for testing vs defaulting to Master
$ pip install -r requirements.txt


* Note: This will install a local copy of the Loads tool for use with TokenServer.
== Running the load test against Sync 1.5 in Stage ==
* Loads against specific Sync nodes in Stage
$ export SERVER_URL=https://your.storagenode.here#SECRET
Sync Stage nodes:
    https://sync-1-us-east-1.stage.mozaws.net
    https://sync-2-us-east-1.stage.mozaws.net
    ...etc...
NOTE: The OPs team has the SECRET string for Stage. Get it from them before you start testing.


== Running the Loads tool against TokenServer in Stage ==
* Load testing with Molotov: https://molotov.readthedocs.io/en/stable/
* TBD
$ bin/molotov [commands] loadtest.py
 
== Using the Loads V1 Services Cluster for Sync 1.5 in Stage ==
* loadtesting from server-syncstorage has been deprecated, please refer to mozilla-services/syncstorage-loadtest
** https://github.com/mozilla-services/server-syncstorage/tree/master/loadtest


* NOTE: only one load test can be run at a time against FxA Stage since we are making use of the Loads environment broker and agents. Allow a load test to finish before starting a new load test. See below for more information...
== Running a combined load test against TokenServer+Verifier and Sync 1.5 in Stage ==
* A combined loads test against TokenServer and Sync 1.5 in Stage
* This is done via the server-syncstorage directory that was cloned and built above
$ cd server-syncstorage
$ cd loadtest
$ make test SERVER_URL=https://your.tokenserver.here
$ make bench SERVER_URL=https://your.tokenserver.here
Examples for Stage:
$ make test SERVER_URL=https://token.stage.mozaws.net
$ make bench SERVER_URL=https://token.stage.mozaws.net
See https://wiki.mozilla.org/QA/Services/TSVerifierSyncTestEnvironments#TokenServer.2BVerifier_Stage_Environment
Note: the current version of 'make bench' tends to use a lot of CPU and Memory on the localhost.   
The recommendation is to use 'make test' and 'make megabench' instead (see below)...
Note: The Stage Tokenserver hits the Stage Verifier, which, in turn, hits the mockmyid server.


* NOTE: Also, we can configure the load test (make bench) to run in detached mode with an appropriate observer. See below for more information...
* And while we are at it...
Dev environment:
Examples:
$ make test SERVER_URL=https://token.dev.lcip.org
$ make bench SERVER_URL=https://token.dev.lcip.org
Prod environment:
Examples:
$ make test SERVER_URL=https://token.services.mozilla.com
$ make bench SERVER_URL=https://token.services.mozilla.com
See https://wiki.mozilla.org/QA/Services/FxATestEnvironments#FxA.2C_TokenServer.2C_and_Sync_Production_Environments
and https://wiki.mozilla.org/QA/Services/TSVerifierSyncTestEnvironments#TokenServer_and_Sync_1.5_Dev_Environments


== Installing the Loads tool on the AWS instance for Sync 1.5 ==
== Using the Loads V1 Services Cluster for a combined load test in Stage ==
Installation:
* By using the Loads Services Cluster, we can offload the broker/agents processes and save client-side CPU and memory.
  $ TBD
* Changes were made to Makefile and the load test to use the cluster and some associated config files (for test, bench, megabench).
* Stage environment:
  $ make megabench SERVER_URL=https://token.stage.mozaws.net


* Note: This will install a local copy of the Loads tool for use with TokenServer.
* Dev environment:
$ make megabench SERVER_URL=https://token.dev.lcip.org


== Running the Loads tool against Sync 1.5 in Stage ==
* Prod environment:
* Loads against specific Sync nodes in Stage- TBD
$ make megabench SERVER_URL=https://token.services.mozilla.com


* NOTE: only one load test can be run at a time against FxA Stage since we are making use of the Loads environment broker and agents. Allow a load test to finish before starting a new load test. See below for more information...
* REFs:
** https://wiki.mozilla.org/QA/Services/LoadsToolsAndTesting1
** https://github.com/mozilla-services/server-syncstorage/tree/master/loadtest


* NOTE: Also, we can configure the load test (make bench) to run in detached mode with an appropriate observer. See below for more information...
== Configuring The Load Tests ==
* Makefile
** The SERVER_URL constant can be changed.


== Running the Loads tool against TokenServer and Sync 1.5 in Stage ==
* Config files
* A combined loads test against TokenServer and Sync 1.5 in Stage - TBD
** For make test (BrowserID-Verifier, TokenServer, Sync, Combined):
*** Number of hits
*** Number of concurrent users


* NOTE: only one load test can be run at a time against FxA Stage since we are making use of the Loads environment broker and agents. Allow a load test to finish before starting a new load test. See below for more information...
** For make bench (BrowserID-Verifier, TokenServer, Sync, Combined):
*** Number of concurrent users
*** Duration of test


* NOTE: Also, we can configure the load test (make bench) to run in detached mode with an appropriate observer. See below for more information...
** For make megabench (using the LoadsCluster with BrowserID-Verifier, TokenSerer, Sync, Combined):
*** Number of concurrent users
*** Duration of test
*** Include file (this is code dependent)
*** Python dependencies (this is code dependent)
*** Agents to use for testing (default is 5, max is currently 20, but depends on the number of concurrent load tests running)
*** Detach mode (leave as defined for now to automatically detach from the load test once it starts on the localhost)
*** Observer (this can be email or irc - the default is irc #services-dev channel)  
*** SSH (the user account needed to SSH into the loads cluster - the default is ubuntu)


== Using the Loads Test environment ==
* Tokenserver load test code
* For the broker and agents - will probably have Dev create a temporary addition to the Make file and tools to allow for a "make megabench" that will run a "make bench" but use the Loads Test environment broker and agent set up.
** The Tokenserver load test can be configured - see the following lines:
** See https://github.com/mozilla-services/tokenserver/issues/41
** Basic Settings: https://github.com/mozilla-services/loop-server/blob/master/loadtests/loadtest.py
** MockMyID: https://github.com/mozilla-services/tokenserver/blob/master/loadtest/loadtest.py#L19-L36
** Percentages: https://github.com/mozilla-services/tokenserver/blob/master/loadtest/loadtest.py#L39-L51


* Note: normally, we can only run one load test at a time with this environment, since it was not designed to share the broker and all the agents. If you attempt to run two loads tests with this environment, you will probably get a failure that looks something like this:
* Verifier load test code
ExecutionError: Not enough agents running on that broker
** The Verifier load test can be configured - see the following lines:
** Various settings: https://github.com/mozilla/browserid-verifier/blob/master/loadtest/loadtest.py#L13-L53


* We can, with the proper permissions, SSH into the environment and restart the broker and agent processes.
* Sync Server load test code
** The Sync Server load test can be configured - see the following lines:
** Setting MockMyID: https://github.com/mozilla-services/server-syncstorage/blob/master/loadtest/stress.py#L26-L45
** Setting test distributions: https://github.com/mozilla-services/server-syncstorage/blob/master/loadtest/stress.py#L48-L83


== Using the Loads Services cluster ==
* REFs:
* To get around the issues with using the loads tool on a local host
** https://github.com/mozilla-services/tokenserver/blob/master/loadtest/loadtest.py
* And as an alternative to Detached Mode and Observers
** https://github.com/mozilla/browserid-verifier/blob/master/loadtest/loadtest.py
* TBD
** https://github.com/mozilla-services/server-syncstorage/blob/master/loadtest/stress.py


== Test Coverage and Stats ==
== Test Coverage and Stats ==
* Basic tweakable values for all load tests
** users = number of concurrent users/agent
** agents = number of agents out of the cluster, otherwise errors out
** duration = in seconds
** hits = 1 or X number of rounds/hits/iterations
* TokenServer
** File location: tokenserver/loadtest/loadtest.py
** Inside NoteAssignmentTest, test_realistic is the main load test; the others are for specific behaviors
** The test runs as following:
95% ask for assertions on existing users (on a DB filled by test_single_token_exchange)
4% ask for assertion on a new use
1% ask for a bad assertion
** A bug has been filed to get the following additional coverage for the load test:
*** generation numbers in assertion
*** client state string
** A bug has been filed to get some integration tests written:
*** to cover the edge/error cases not in the load test
*** to be pointed at a remote server
* Sync
** File location: server-syncstorage/loadtest/stress.py
** This is the Sync 2.0 load test that has been back-ported for Sync 1.5.
** The stress.py file is fully configurable for the following:
*** client probability
*** client distribution
*** collections
** A bug has been filed to add support for load testing tabs
*** The tab collection it uses memcache; we need to figure out a way to test it without overloading the server
** There are currently no constants to define how to select percentages per collection type
** Right now, we need to manually configure the collections list in stress.py:
*** collections = ['bookmarks', 'forms', 'passwords', 'history', 'prefs']
*** Basically, you can add more entries of each type, since the load test (per user/again/hit/pass) picks randomly from the list for any given request...
== Analyzing the Results ==
* There are several methods and tools for analyzing the load test results.
* 1. Using the Loads Services Cluster dashboard
** All loads tests using this cluster generate a live report and a run report available on this site:
*** http://loads.services.mozilla.com
*** or http://ec2-54-212-44-143.us-west-2.compute.amazonaws.com (direct)
** You can quickly review the following here: Status, Configuration, Results, Custom Metrics, and Errors.
* Tokenserver Custom Metrics
** addFailure
* Verifier Custom Metrics
** addFailure
* Sync Custom Metrics
** addFailure
* NOTE: If you want more details on the dashboard, please file an issue here: https://github.com/mozilla-services/loads
== Debugging the Issues ==
* There are several methods and tools for debugging the load test errors and other issues.
* 1. Important logs for TokenServer (per server)
** /media/ephemeral0/logs/
** /media/ephemeral0/nginx/logs/default.access.log
** /media/ephemeral0/nginx/logs/default.error.log
** /media/ephemeral0/nginx/logs/tokenserver.access.log
** /media/ephemeral0/nginx/logs/tokenserver.error.log
** /media/ephemeral0/logs/tokenserver/token.error.log
** /media/ephemeral0/logs/tokenserver/token.log.*
** /media/ephemeral0/logs/tokenserver/process_account_deletions.error.log
** /media/ephemeral0/logs/tokenserver/process_account_deletions.log
** /media/ephemeral0/logs/tokenserver/purge_old_records.log
** /media/ephemeral0/logs/tokenserver/purge_old_records.error.log
** /media/ephemeral0/fxa-browserid-verifier/verifier_err.log
** /media/ephemeral0/fxa-browserid-verifier/verifier_out.log
** /var/log/circus.log
** /var/log/hekad/tokenserver.stdout.log
** /var/log/hekad/tokenserver.stderr.log
* 2. Important logs for Verifier (per server)
** /media/ephemeral0/fxa-browserid-verifier/verifier_err.log
** /media/ephemeral0/fxa-browserid-verifier/verifier_out.log
** /media/ephemeral0/nginx/logs/fxa-browserid-verifier.access.log
** /media/ephemeral0/nginx/logs/fxa-browserid-verifier.access.log
** /media/ephemeral0/nginx/logs/default.access.log (not in use)
** /media/ephemeral0/nginx/logs/default.error.log (not in use)
** /media/ephemeral0/squid/access.log
** /var/log/circus.log
** /var/log/hekad/fxa-browserid_verifier.stderr.log
** /var/log/hekad/fxa-browserid_verifier.stdout.log
* 3. Important error logs for Sync (per Sync node)
** /media/ephemeral0/logs/
** /media/ephemeral0/nginx/access.log
** /media/ephemeral0/error.log
** /media/ephemeral0/sync/sync.err
** /media/ephemeral0/sync/sync.log
* Acceptable TokenServer errors:
1% - 2% failures (as the following)
token.log:
"name": "token.assertion.invalid_signature_error"
"name": "token.assertion.verify_failure"
nginx access.log:
401s
NOTE: Values can be tweaked here:
    https://github.com/mozilla-services/tokenserver/blob/master/loadtest/loadtest.py#L58-L60
The following types of errors are known:
/media/ephemeral0/logs/tokenserver/token.error.log
    Exception KeyError: KeyError(49564400,) in <module 'threading'...
/media/ephemeral0/logs/tokenserver/token.log
    ..."Starting new HTTP connection (9): 127.0.0.1", "hostname": ...
    {"error": "StopIteration()", "traceback": "Uncaught exception:\n 
    File \"/data/tokenserver/local/lib/python2.6/site-packages/gunicorn/workers/async.py\"...
    ..."Connection pool is full, discarding connection: 127.0.0.1", "...
Also, any 499s are probably an artifact of the current (V1) load test.
REF:
https://bugzilla.mozilla.org/show_bug.cgi?id=1040396
https://bugzilla.mozilla.org/show_bug.cgi?id=1040397
OLD: Also, it may be the case that the following errors are "acceptable" if TS Stage is larger than Verifier Stage:
/media/ephemeral0/logs/tokenserver/token.error.log
Verifier-related errors of these types:
"HttpConnectionPool is full, discarding connection: verifier.stage.mozaws.net"
"Resetting dropped connection: verifier.stage.mozaws.net"
"Starting new HTTPS connection (179): verifier.stage.mozaws.net"
* Acceptable Verifier errors:
The verifier_out.log will show errors of the following types:
result: 'failure',\n  reason: 'untrusted issuer...'
result: 'failure',\n  reason: 'expired'
result: 'failure',\n  reason: 'algorithms do not match'
result: 'failure',\n  reason: 'audience mismatch: scheme mismatch'
Also, any 499s in the nginx logs are probably an artifact of the current (V1) load test.
* Acceptable Sync node errors:
In the nginx access.log files:
We will see some percentage of 404s. Right now we see the following:
    14% 404s (compared to the total count of 200s)
    with the config set up as follows:
          users = 20
          duration = 1800
          agents = 5
Ideally, the overall percentage of 404s should drop the longer the load test.
Usually, you will not see 304s, 400s, 412s, or 415s for a load test,
although they may show up in the logs after running the remote integration tests.
Also, any 499s are probably an artifact of the current (V1) load test.
In /var/log/hekad/sync_1_5.stderr.log
You may see some Decoder 'Sync-1_5-SlowQuery-MySqlSlowQueryDecoder' error: Failed parsing
and a lot of BSO INSERTs
In /media/ephemeral0/logs/sync/sync.err
You should see expected skew and QueuePool messages and Deprecation warnings
Also, these are known
Exception SystemExit
Exception KeyError
This is probably https://bugzilla.mozilla.org/show_bug.cgi?id=1040397
== Monitoring TS and Sync Stage ==
* Loads dashboard:
** http://loads.services.mozilla.com
* Cluster status
** Check directly from the Loads Cluster dashboard:
Agents statuses
Launch a health check on all agents
* and also on StackDriver: https://app.stackdriver.com/groups/6664/stage-loads-cluster
* For all other monitoring, see the following section:
** https://wiki.mozilla.org/QA/Services/TSVerifierSyncTestEnvironments#Monitoring_the_Stage_Environment
== Performance Testing Information ==
* TBD
* TBD
== Monitoring FxA Stage ==
* OPs has set up two dashboards for monitoring Stage:
** https://kibana.shared.us-east-1.stage.mozaws.net/#/dashboard/file/weblogs.json
** https://heka.shared.us-east-1.stage.mozaws.net/#health
* NOTE: There is currently a bug that makes it difficult to access these pages in Fx without adding a certificate exception. The use of the Mozilla cert "should" get around this, but the bug remains...
* NOTE: Also, TokenServer Stage and Sync 1.5 Stage are not currently hooked up into the hekad --> elasticsearch --> kibana pipeline. See https://github.com/mozilla-services/puppet-config/issues/120


== Details on the Load Test tool ==
== Details on the Load Test tool ==
* The documentation can be found here:
* The documentation can be found here:
** https://loads.readthedocs.org/en/latest
** https://loads.readthedocs.org/en/latest
** The most useful information here is running in detached mode and using an observer
*** https://loads.readthedocs.org/en/latest/distributed/#detach-mode
*** https://loads.readthedocs.org/en/latest/commands
*** and here: https://loads.readthedocs.org/en/latest/internals/?highlight=observer
* The repositories are here:
* The repositories are here:
** https://github.com/mozilla-services/loads
** https://github.com/mozilla-services/loads
** https://github.com/mozilla-services/loads.js
** https://github.com/mozilla-services/loads-aws
** https://github.com/mozilla-services/loads-web
* The Services cluster is here:
* The Services cluster is here:
** http://loads.services.mozilla.com
** http://loads.services.mozilla.com


== Known Issues ==
== Known Bugs, Issues, and Tasks ==
* TokenServer and Sync
* Tokenserver:  
** https://github.com/mozilla-services/tokenserver/issues/22
** Repo: https://github.com/mozilla-services/tokenserver/issues  
** https://github.com/mozilla-services/tokenserver/issues/32
** Bugzilla: http://mzl.la/1s4qZKn
** https://github.com/mozilla-services/tokenserver/issues/33
** https://github.com/mozilla-services/tokenserver/issues/34
** https://github.com/mozilla-services/tokenserver/issues/35
** https://github.com/mozilla-services/tokenserver/issues/36
** https://github.com/mozilla-services/tokenserver/issues/37
** https://github.com/mozilla-services/tokenserver/issues/38
** https://github.com/mozilla-services/tokenserver/issues/39
** https://github.com/mozilla-services/tokenserver/issues/40
** https://github.com/mozilla-services/tokenserver/issues/41
** https://github.com/mozilla-services/server-syncstorage/issues/7
** https://bugzilla.mozilla.org/show_bug.cgi?id=956217
** https://bugzilla.mozilla.org/show_bug.cgi?id=969190
** https://bugzilla.mozilla.org/show_bug.cgi?id=969184
** https://bugzilla.mozilla.org/show_bug.cgi?id=968396
** https://bugzilla.mozilla.org/show_bug.cgi?id=967987
** https://bugzilla.mozilla.org/show_bug.cgi?id=969209
** https://bugzilla.mozilla.org/show_bug.cgi?id=968607
** https://bugzilla.mozilla.org/show_bug.cgi?id=968633
** https://bugzilla.mozilla.org/show_bug.cgi?id=878107
** https://bugzilla.mozilla.org/show_bug.cgi?id=965672
** https://bugzilla.mozilla.org/show_bug.cgi?id=963342
** https://bugzilla.mozilla.org/show_bug.cgi?id=964522
 
** We are still diagnosing issues in the Stage environment. The most current, short run on 2/6/2014 showed the following: TBD
* See also https://bugzilla.mozilla.org/show_bug.cgi?id=968455
* And https://bugzilla.mozilla.org/show_bug.cgi?id=968396


* Kibana
* BrowserID-Verifier:
** https://github.com/mozilla/fxa-deployment/issues/32
** Repo: https://github.com/mozilla/browserid-verifier/issues
** Note: We can, with proper privileges, SSH into the log aggregator and restart the elasticsearch and hekad processes.
** Bugzilla: no specific cateogory


* Infrastructure
* Sync:
** https://github.com/mozilla-services/puppet-config/issues/62
** Repo: https://github.com/mozilla-services/server-syncstorage/issues
** https://github.com/mozilla-services/puppet-config/pull/65
** Bugzilla: http://mzl.la/VUrYQ5
** https://github.com/mozilla-services/puppet-config/issues/79
** https://github.com/mozilla-services/puppet-config/issues/81
** https://github.com/mozilla-services/puppet-config/issues/82
** https://github.com/mozilla-services/puppet-config/issues/83
** https://github.com/mozilla-services/puppet-config/issues/84
** https://github.com/mozilla-services/puppet-config/issues/85
** https://github.com/mozilla-services/puppet-config/issues/86
** https://github.com/mozilla-services/puppet-config/issues/101
** https://github.com/mozilla-services/puppet-config/issues/103
** https://github.com/mozilla-services/puppet-config/issues/104
** https://github.com/mozilla-services/puppet-config/issues/105
** https://github.com/mozilla-services/puppet-config/issues/113
** https://github.com/mozilla-services/puppet-config/issues/114
** https://github.com/mozilla-services/puppet-config/issues/116
** https://github.com/mozilla-services/puppet-config/issues/117
** https://github.com/mozilla-services/puppet-config/issues/118
** https://github.com/mozilla-services/puppet-config/pull/119
** https://github.com/mozilla-services/puppet-config/issues/120
** https://github.com/mozilla-services/svcops-oompaloompas/issues/18
** https://github.com/mozilla-services/svcops-oompaloompas/issues/21
** https://github.com/mozilla-services/svcops-oompaloompas/issues/24


* Loads Tool and clusters
* OPs and Infrastructure
** https://github.com/mozilla-services/loads/issues/181
** https://github.com/mozilla-services/puppet-config/issues
** https://github.com/mozilla-services/loads/issues/198
** https://github.com/mozilla-services/svcops/issues
** https://github.com/mozilla-services/loads/issues/199
** https://github.com/mozilla-services/loads/issues/200


* Because of the issues listed above, the Loads tool team is working on some fixes for better use of the tool in detached mode with a given observer that will allow us to send the test output to a specific email or a given IRC channel.
* Loads Tool and Cluster
* The team is also looking at performing all FxA loads testing through the Services cluster.
** https://github.com/mozilla-services/loads/issues
** https://github.com/mozilla-services/loads-aws/issues
** https://github.com/mozilla-services/loads-web/issues


== References ==
== References ==
* Other URLs
** http://restmail.net
** https://mockmyid.com
* Repositories
* Repositories
** https://github.com/mozilla-services/tokenserver
** https://github.com/mozilla-services/tokenserver
** https://github.com/mozilla-services/server-syncstorage
** https://github.com/mozilla-services/server-syncstorage
* The QA Test Environments: https://wiki.mozilla.org/QA/Services/FxATestEnvironments
** https://github.com/mozilla/browserid-verifier
** https://github.com/mozilla/browserid-local-verify
** https://github.com/callahad/mockmyid
** https://github.com/mozilla/restmail.net
* Documentation
** https://docs.services.mozilla.com
** https://docs.services.mozilla.com/token/
** https://wiki.mozilla.org/Services/Sagrada/TokenServer
** https://docs.services.mozilla.com/sync/
* The QA Test Environments:  
** https://wiki.mozilla.org/QA/Services/FxATestEnvironments
** https://wiki.mozilla.org/QA/Services/TSVerifierSyncTestEnvironments
* Deploying the FxA Load Test environment for broker/agents usage:
* Deploying the FxA Load Test environment for broker/agents usage:
** https://github.com/mozilla/fxa-deployment
** https://github.com/mozilla/fxa-deployment
* Sync 1.5 protocol, documentation, etc.
* Sync 1.5 protocol, documentation, etc.
** https://bugzilla.mozilla.org/show_bug.cgi?id=951986
** https://github.com/mozilla-services/docs
** https://bugzilla.mozilla.org/show_bug.cgi?id=960876
** https://docs.services.mozilla.com/#how-to
** https://bugzilla.mozilla.org/show_bug.cgi?id=960878
** https://docs.services.mozilla.com/howtos/run-fxa.html
** https://bugzilla.mozilla.org/show_bug.cgi?id=963332
** https://docs.services.mozilla.com/token/apis.html
** https://bugzilla.mozilla.org/show_bug.cgi?id=817950
** https://docs.services.mozilla.com/storage/apis-1.5.html
** https://bugzilla.mozilla.org/show_bug.cgi?id=817941
** https://docs.services.mozilla.com/howtos/run-sync-1.5.html
** https://bugzilla.mozilla.org/show_bug.cgi?id=968032
** https://docs.services.mozilla.com/howtos/run-sync-1.5.html
** https://bugzilla.mozilla.org/show_bug.cgi?id=967285
** https://github.com/mozilla-services/syncserver
** https://github.com/mozilla-services/server-syncstorage/pull/8
* OPs pages for stats collection, logging, monitoring
* OPs pages for stats collection, logging, monitoring
** TBD
** TBD

Latest revision as of 14:32, 1 March 2019

  • NOTE: We currently have two Verifier stacks in Stage (and probably Production):
    • The standalone Browser_ID Verifier stack: See that Verifier sections below...
    • A Tokenserver+Verifier stack: See the TokenServer sections below...


Quick Verification Of Stage Deployments

  • This is a quick sanity test of the environment before getting started on load tests.
  • TokenServer+Verifier Stage environment:
From the browser: https://token.stage.mozaws.net
curl https://token.stage.mozaws.net
curl -I https://token.stage.mozaws.net

Use the simple "make test" command from an install of tokenserver on the localhost or AWS instance.
cd loadtest
make test SERVER_URL=https://token.stage.mozaws.net

Alternate method:
Use the test tool from here: https://github.com/edmoz/fxa-sync-client
Install and check all collection types for a known account in Stage:
bin/sync-cli.js -e EMAIL -p PASSWORD --env stage -t COLLECTION
    where -t is one of bookmarks,history,passwords,tabs,addons,prefs,forms
  • Verifier Stage environment:
In the browser: https://verifier.stage.mozaws.net/
curl https://verifier.stage.mozaws.net
curl -I https://verifier.stage.mozaws.net

Use the simple "make test" command from an install of browserid-verifier on the localhost or AWS instance.
cd loadtest
make test SERVER_URL=https://verifier.stage.mozaws.net
  • Sync Server Stage environment:
Install server-syncstorage to the local host or AWS instance (see below)
$ cd server-syncstorage
Quick test against the TokenServer
$ ./local/bin/python ./syncstorage/tests/functional/test_storage.py --use-token-server <Stage TokenServer>
Current example:
$ ./local/bin/python ./syncstorage/tests/functional/test_storage.py --use-token-server 
    https://token.stage.mozaws.net/1.0/sync/1.5
Quick tests against the Sync nodes
$ ./local/bin/python ./syncstorage/tests/functional/test_storage.py <Stage Sync Node>#<Node Secret>
Current examples:
$ ./local/bin/python ./syncstorage/tests/functional/test_storage.py 
    https://sync-1-us-east-1.stage.mozaws.net#<Node Secret>
$ ./local/bin/python ./syncstorage/tests/functional/test_storage.py 
    https://sync-1-us-east-1.stage.mozaws.net#<Node Secret>
$ ./local/bin/python ./syncstorage/tests/functional/test_storage.py 
    https://sync-1-us-east-1.stage.mozaws.net#<Node Secret>
Get the Node Secret information from OPs

Quick Verification Of Production Deployments

  • This is a quick sanity test of the environment after a new deployment.
  • Tokenserver+Verifier Production Environment
In the browser: https://token.services.mozilla.com
curl https://token.services.mozilla.com
curl -I https://token.services.mozilla.com
Then:
Use the test tool from here: https://github.com/edmoz/fxa-sync-client
Install and check all collection types for a known account in Production:
bin/sync-cli.js -e PROD-EMAIL -p PASSWORD -t COLLECTION
    where -t is one of bookmarks,history,passwords,tabs,addons,prefs,forms
  • Verifier Production Environment
In the browser: https://verifier.accounts.firefox.com
curl https://verifier.accounts.firefox.com
curl -I https://verifier.accounts.firefox.com
Then:
Use the simple "make test" command from an install of browserid-verifier on the localhost or AWS instance.
cd loadtest
make test SERVER_URL=https://verifier.accounts.firefox.com
  • Sync Server Stage environment
Sign in with a known FxA account and sync data with a current Production account (sync node).
Create a new FxA account and set up sync.

Load Test Tool Client/Host

Installing BrowserID-Verifier and the Loads tool on Localhost or AWS

  • Installation:
$ git clone git://github.com/mozilla/browserid-verifier
$ cd browserid-verifier
Note: You may want to install a specific branch for testing vs defaulting to Master
$ npm install
$ npm test
$ cd loadtest
$ make build
     Note: This should hit Stage by default: SERVER_URL=https://verifier.stage.mozaws.net
  • Note: This will install a local copy of the Loads tool for use with the verifier.

Running the load test against the Verifier in Stage

  • Stage environment:
$ make test
or
$ make test SERVER_URL=https://verifier.stage.mozaws.net
$ make bench
or
$ make bench SERVER_URL=https://verifier.stage.mozaws.net	

Note: the current version of 'make bench' tends to use a lot of CPU and Memory on the localhost.    
The recommendation is to use 'make test' and 'make megabench' instead (see below)...
Note: The Stage Verifier hits the Stage mockmyid server
  • Production environment:
$ make test SERVER_URL=https://verifier.accounts.firefox.com
$ make bench SERVER_URL=https://verifier.accounts.firefox.com

Using the Loads V1 Services Cluster for the Verifier

  • By using the Loads Services Cluster, we can offload the broker/agents processes and save client-side CPU and memory.
  • Changes were made to Makefile and the load test to use the cluster and some associated config files (for test, bench, megabench).
  • Stage environment:
$ make megabench SERVER_URL=https://verifier.stage.mozaws.net
  • Dev environment:
$ make megabench SERVER_URL=TBD
  • Production environment:
$ make megabench SERVER_URL=https://verifier.accounts.firefox.com

Installing TokenServer+Verifier and the Loads tool on Localhost or AWS

  • Installation:
$ git clone https://github.com/mozilla-services/tokenserver
$ cd tokenserver
Note: You may want to install a specific branch for testing vs defaulting to Master
$ make build
$ make test
    Note: This is for local testing only
$ cd loadtest
$ make build
    Note: This should hit Prod by default: SERVER_URL=https://token.services.mozilla.com
  • Note: This will install a local copy of the Loads tool for use with TokenServer+Verifier.

Running the load test against TokenServer+Verifier in Stage

  • Stage environment:
$ make test SERVER_URL=https://token.stage.mozaws.net
$ make bench SERVER_URL=https://token.stage.mozaws.net		

Note: the current version of 'make bench' tends to use a lot of CPU and Memory on the localhost.    
The recommendation is to use 'make test' and 'make megabench' instead (see below)...
Note: This also hits the Stage Verifier, which in turns hits the Stage mockmyid server
  • And while we are at it...
  • Dev environment:
$ make test SERVER_URL=https://token.dev.lcip.org
$ make bench SERVER_URL=https://token.dev.lcip.org
  • Production environment:
$ make test SERVER_URL=https://token.services.mozilla.com
$ make bench SERVER_URL=https://token.services.mozilla.com

Using the Loads V1 Services Cluster for TokenServer+Verifier

  • By using the Loads Services Cluster, we can offload the broker/agents processes and save client-side CPU and memory.
  • Changes were made to Makefile and the load test to use the cluster and some associated config files (for test, bench, megabench).
  • Stage environment:
$ make megabench SERVER_URL=https://token.stage.mozaws.net
  • Dev environment:
$ make megabench SERVER_URL=https://token.dev.lcip.org
  • Production environment:
$ make megabench SERVER_URL=https://token.services.mozilla.com

Installing Sync and load testing on Localhost or AWS

Installation:
$ git clone https://github.com/mozilla-services/syncstorage-loadtest/
$ cd syncstorage-loadtest
Note: You may want to install a specific branch for testing vs defaulting to Master
$ pip install -r requirements.txt

Running the load test against Sync 1.5 in Stage

  • Loads against specific Sync nodes in Stage
$ export SERVER_URL=https://your.storagenode.here#SECRET
Sync Stage nodes:
    https://sync-1-us-east-1.stage.mozaws.net
    https://sync-2-us-east-1.stage.mozaws.net
    ...etc...

NOTE: The OPs team has the SECRET string for Stage. Get it from them before you start testing.
$ bin/molotov [commands] loadtest.py

Using the Loads V1 Services Cluster for Sync 1.5 in Stage

Running a combined load test against TokenServer+Verifier and Sync 1.5 in Stage

  • A combined loads test against TokenServer and Sync 1.5 in Stage
  • This is done via the server-syncstorage directory that was cloned and built above
$ cd server-syncstorage
$ cd loadtest
$ make test SERVER_URL=https://your.tokenserver.here
$ make bench SERVER_URL=https://your.tokenserver.here

Examples for Stage:
$ make test SERVER_URL=https://token.stage.mozaws.net
$ make bench SERVER_URL=https://token.stage.mozaws.net
See https://wiki.mozilla.org/QA/Services/TSVerifierSyncTestEnvironments#TokenServer.2BVerifier_Stage_Environment

Note: the current version of 'make bench' tends to use a lot of CPU and Memory on the localhost.    
The recommendation is to use 'make test' and 'make megabench' instead (see below)...
Note: The Stage Tokenserver hits the Stage Verifier, which, in turn, hits the mockmyid server.
  • And while we are at it...
Dev environment:
Examples:
$ make test SERVER_URL=https://token.dev.lcip.org
$ make bench SERVER_URL=https://token.dev.lcip.org

Prod environment:
Examples:
$ make test SERVER_URL=https://token.services.mozilla.com
$ make bench SERVER_URL=https://token.services.mozilla.com

See https://wiki.mozilla.org/QA/Services/FxATestEnvironments#FxA.2C_TokenServer.2C_and_Sync_Production_Environments
and https://wiki.mozilla.org/QA/Services/TSVerifierSyncTestEnvironments#TokenServer_and_Sync_1.5_Dev_Environments

Using the Loads V1 Services Cluster for a combined load test in Stage

  • By using the Loads Services Cluster, we can offload the broker/agents processes and save client-side CPU and memory.
  • Changes were made to Makefile and the load test to use the cluster and some associated config files (for test, bench, megabench).
  • Stage environment:
$ make megabench SERVER_URL=https://token.stage.mozaws.net
  • Dev environment:
$ make megabench SERVER_URL=https://token.dev.lcip.org
  • Prod environment:
$ make megabench SERVER_URL=https://token.services.mozilla.com

Configuring The Load Tests

  • Makefile
    • The SERVER_URL constant can be changed.
  • Config files
    • For make test (BrowserID-Verifier, TokenServer, Sync, Combined):
      • Number of hits
      • Number of concurrent users
    • For make bench (BrowserID-Verifier, TokenServer, Sync, Combined):
      • Number of concurrent users
      • Duration of test
    • For make megabench (using the LoadsCluster with BrowserID-Verifier, TokenSerer, Sync, Combined):
      • Number of concurrent users
      • Duration of test
      • Include file (this is code dependent)
      • Python dependencies (this is code dependent)
      • Agents to use for testing (default is 5, max is currently 20, but depends on the number of concurrent load tests running)
      • Detach mode (leave as defined for now to automatically detach from the load test once it starts on the localhost)
      • Observer (this can be email or irc - the default is irc #services-dev channel)
      • SSH (the user account needed to SSH into the loads cluster - the default is ubuntu)

Test Coverage and Stats

  • Basic tweakable values for all load tests
    • users = number of concurrent users/agent
    • agents = number of agents out of the cluster, otherwise errors out
    • duration = in seconds
    • hits = 1 or X number of rounds/hits/iterations
  • TokenServer
    • File location: tokenserver/loadtest/loadtest.py
    • Inside NoteAssignmentTest, test_realistic is the main load test; the others are for specific behaviors
    • The test runs as following:
95% ask for assertions on existing users (on a DB filled by test_single_token_exchange)
4% ask for assertion on a new use
1% ask for a bad assertion
    • A bug has been filed to get the following additional coverage for the load test:
      • generation numbers in assertion
      • client state string
    • A bug has been filed to get some integration tests written:
      • to cover the edge/error cases not in the load test
      • to be pointed at a remote server
  • Sync
    • File location: server-syncstorage/loadtest/stress.py
    • This is the Sync 2.0 load test that has been back-ported for Sync 1.5.
    • The stress.py file is fully configurable for the following:
      • client probability
      • client distribution
      • collections
    • A bug has been filed to add support for load testing tabs
      • The tab collection it uses memcache; we need to figure out a way to test it without overloading the server
    • There are currently no constants to define how to select percentages per collection type
    • Right now, we need to manually configure the collections list in stress.py:
      • collections = ['bookmarks', 'forms', 'passwords', 'history', 'prefs']
      • Basically, you can add more entries of each type, since the load test (per user/again/hit/pass) picks randomly from the list for any given request...

Analyzing the Results

  • There are several methods and tools for analyzing the load test results.
  • Tokenserver Custom Metrics
    • addFailure
  • Verifier Custom Metrics
    • addFailure
  • Sync Custom Metrics
    • addFailure

Debugging the Issues

  • There are several methods and tools for debugging the load test errors and other issues.
  • 1. Important logs for TokenServer (per server)
    • /media/ephemeral0/logs/
    • /media/ephemeral0/nginx/logs/default.access.log
    • /media/ephemeral0/nginx/logs/default.error.log
    • /media/ephemeral0/nginx/logs/tokenserver.access.log
    • /media/ephemeral0/nginx/logs/tokenserver.error.log
    • /media/ephemeral0/logs/tokenserver/token.error.log
    • /media/ephemeral0/logs/tokenserver/token.log.*
    • /media/ephemeral0/logs/tokenserver/process_account_deletions.error.log
    • /media/ephemeral0/logs/tokenserver/process_account_deletions.log
    • /media/ephemeral0/logs/tokenserver/purge_old_records.log
    • /media/ephemeral0/logs/tokenserver/purge_old_records.error.log
    • /media/ephemeral0/fxa-browserid-verifier/verifier_err.log
    • /media/ephemeral0/fxa-browserid-verifier/verifier_out.log
    • /var/log/circus.log
    • /var/log/hekad/tokenserver.stdout.log
    • /var/log/hekad/tokenserver.stderr.log
  • 2. Important logs for Verifier (per server)
    • /media/ephemeral0/fxa-browserid-verifier/verifier_err.log
    • /media/ephemeral0/fxa-browserid-verifier/verifier_out.log
    • /media/ephemeral0/nginx/logs/fxa-browserid-verifier.access.log
    • /media/ephemeral0/nginx/logs/fxa-browserid-verifier.access.log
    • /media/ephemeral0/nginx/logs/default.access.log (not in use)
    • /media/ephemeral0/nginx/logs/default.error.log (not in use)
    • /media/ephemeral0/squid/access.log
    • /var/log/circus.log
    • /var/log/hekad/fxa-browserid_verifier.stderr.log
    • /var/log/hekad/fxa-browserid_verifier.stdout.log
  • 3. Important error logs for Sync (per Sync node)
    • /media/ephemeral0/logs/
    • /media/ephemeral0/nginx/access.log
    • /media/ephemeral0/error.log
    • /media/ephemeral0/sync/sync.err
    • /media/ephemeral0/sync/sync.log


  • Acceptable TokenServer errors:
1% - 2% failures (as the following)
token.log:
"name": "token.assertion.invalid_signature_error"
"name": "token.assertion.verify_failure"
nginx access.log:
401s
NOTE: Values can be tweaked here:
    https://github.com/mozilla-services/tokenserver/blob/master/loadtest/loadtest.py#L58-L60

The following types of errors are known:
/media/ephemeral0/logs/tokenserver/token.error.log
    Exception KeyError: KeyError(49564400,) in <module 'threading'...
/media/ephemeral0/logs/tokenserver/token.log
    ..."Starting new HTTP connection (9): 127.0.0.1", "hostname": ...
    {"error": "StopIteration()", "traceback": "Uncaught exception:\n  
    File \"/data/tokenserver/local/lib/python2.6/site-packages/gunicorn/workers/async.py\"...
    ..."Connection pool is full, discarding connection: 127.0.0.1", "...
Also, any 499s are probably an artifact of the current (V1) load test.
REF:
https://bugzilla.mozilla.org/show_bug.cgi?id=1040396
https://bugzilla.mozilla.org/show_bug.cgi?id=1040397

OLD: Also, it may be the case that the following errors are "acceptable" if TS Stage is larger than Verifier Stage:
/media/ephemeral0/logs/tokenserver/token.error.log
Verifier-related errors of these types:
"HttpConnectionPool is full, discarding connection: verifier.stage.mozaws.net"
"Resetting dropped connection: verifier.stage.mozaws.net"
"Starting new HTTPS connection (179): verifier.stage.mozaws.net"
  • Acceptable Verifier errors:
The verifier_out.log will show errors of the following types:
result: 'failure',\n  reason: 'untrusted issuer...'
result: 'failure',\n  reason: 'expired'
result: 'failure',\n  reason: 'algorithms do not match'
result: 'failure',\n  reason: 'audience mismatch: scheme mismatch'
Also, any 499s in the nginx logs are probably an artifact of the current (V1) load test.
  • Acceptable Sync node errors:
In the nginx access.log files:
We will see some percentage of 404s. Right now we see the following:
    14% 404s (compared to the total count of 200s)
    with the config set up as follows:
         users = 20
         duration = 1800
         agents = 5
Ideally, the overall percentage of 404s should drop the longer the load test.
Usually, you will not see 304s, 400s, 412s, or 415s for a load test,
although they may show up in the logs after running the remote integration tests.
Also, any 499s are probably an artifact of the current (V1) load test.

In /var/log/hekad/sync_1_5.stderr.log
You may see some Decoder 'Sync-1_5-SlowQuery-MySqlSlowQueryDecoder' error: Failed parsing
and a lot of BSO INSERTs

In /media/ephemeral0/logs/sync/sync.err
You should see expected skew and QueuePool messages and Deprecation warnings
Also, these are known
Exception SystemExit
Exception KeyError
This is probably https://bugzilla.mozilla.org/show_bug.cgi?id=1040397

Monitoring TS and Sync Stage

Agents statuses
Launch a health check on all agents

Performance Testing Information

  • TBD

Details on the Load Test tool

Known Bugs, Issues, and Tasks

References