334
edits
User:Polvi/Spectator:Server Side Interaction: Difference between revisions
Jump to navigation
Jump to search
User:Polvi/Spectator:Server Side Interaction (view source)
Revision as of 20:06, 17 January 2008
, 17 January 2008no edit summary
m (User:Polvi/Spectator:How to Disable Collection Server Side moved to User:Polvi/Spectator:Server Side Interaction: need to broaden the topic) |
No edit summary |
||
| Line 3: | Line 3: | ||
Lucky for us, the server controls how often data is uploaded, how much data, and on what interval. | Lucky for us, the server controls how often data is uploaded, how much data, and on what interval. | ||
= How to stop the extension | = Client/Server interaction = | ||
When Spectator uploads data, it looks at the response code and txt to determine what to do next. By controlling the response, it is possible to fully control how Spectator behaves. | |||
* How Spectator handles HTTP response statuses: [http://mxr.mozilla.org/seamonkey/source/extensions/metrics/src/nsMetricsService.cpp#667 here] | |||
= Rate Limiting via the Spectator Config = | |||
Spectator is configured via an XML config file which is provided as a response to uploading. | |||
There are two limits; time and events. For example, one could set a limit of 200 events over 300 seconds. This give complete control of how much data could potentially be uploaded. | |||
Note: | |||
* If no config is in the response of a client upload, the client will continue with its old config. | |||
= How to limit the number of active clients = | |||
It is possible to control the number of active users if needed. Consider that only 1000 clients are desired, but there are 5000 active. In order to reduce the number of active users, the server would need to respond to 4000 requests with an empty <collectors/> element (see below). Once 4000 users are no longer collecting, no longer respond with a config at all. If no config is received in the response, the client will simply carry on as previously configured. | |||
= How to stop the extension from uploading = | |||
In order to completely turn off Spectator client side, and thus cause it to stop uploading, respond to client requests with the following config: | In order to completely turn off Spectator client side, and thus cause it to stop uploading, respond to client requests with the following config: | ||
| Line 9: | Line 25: | ||
<config> | <config> | ||
<collectors/> | <collectors/> | ||
</config> | </config> | ||
</response> | </response> | ||
= How to temporarily disable uploading = | = How to temporarily disable uploading = | ||
In the event we need to keep the client from uploading, but not have it clear all the data it has collected, the server needs to respond with a 5xx server message. | In the event we need to keep the client from uploading, but not have it clear all the data it has collected, the server needs to respond with a 5xx server message. | ||
= How much data to expect = | |||
Configured with profile, document, and uielement collectors, each post will be about 500 bytes. The files are uploaded on a 5min interval. So, if we had a 10,000 users using non-stop all day (very unlikely), we would be generating a max of 1.3gb (500*10000*(86400 / 300.))/(1024*1024*1024) of data a day. | |||
With typical usage, daily data collection would be roughly as follows: | |||
* 100 clients: 7mb | |||
* | * 1000 clients: 68mb | ||
* | * 10000 clients: 680mb | ||