anchor.diff:  - As well as having a better performing http server, if you are moving a lot of
     traffic you probably want to run multiple http servers. Again, assuming your
     datastore handles it, these should scale linearly.
  -- The admin UI and enroller components should have less load on them, depending
  -  on your use case, but you can run as many as you want for redundancy.
  +- The admin UI component is usually under light load, but you can run as many as you want for redundancy.
   - Foreman check frequency. By default the foreman_check_frequency in the client
  -  configuration is set to 10 minutes. This variable controls how often a client
  -  checks if there are hunts scheduled for it. Adjusting this parameter has two
  -  major affects. Firstly it slows down how fast a hunt ramps up, which
  +  configuration is set to 1 hr. This variable controls how often a client
  +  checks if there are hunts scheduled for it. Increasing this number slows down how fast a hunt ramps up, which
     normalizes the load at the cost of making the hunt slower (this is useful in
  -  large deployments). Secondly, each foreman check incurs a penalty on the
  -  frontend server, as it must queue up a check against the rules. So setting
  -  this to a shorter time increases frontend load. In a large deployment 30-40
  -  minutes is a more reasonable setting.
  -
  +  large deployments). Decreasing this number means clients pick up hunts sooner, but each foreman check incurs a penalty on the frontend server, as it must queue up a check against the rules.
   
   Datastore Performance
   ~~~~~~~~~~~~~~~~~~~~~
   
   If you are not CPU bound on the individual components (workers, http server)
  -then the key performance differentiator will be the datastore. At the moment
  -we ship with a Mysql and a Mongo datastore.
  -
  -- The Mongo datastore is currently unoptimized (Mar 2013). This means there are
  -  a number of hotspots causing performance issues. It is worth noting that the
  -  primary developers work with a proprietary datastore so Mongo performance has
  -  not been made a high priority up until recently. Patches welcome :)
  -
  +then the key performance differentiator will be the datastore. Significant performance improvement work has been done on the MySQL Advanced and SQLite datastores but more can still be done. Improvements here will yield large gains, pull requests welcome :)
   
   Running the GRR HTTP Server In Apache
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  
positive.code: The cron allows for scheduling flows to run regularly on the GRR server.
  This is currently used to collect statistics and do cleanup on the database.
  The cron runs as part of the workers.
  
  
  
  
  Customizing the client
  ----------------------
  
negative.code: 
  Managing the Datastore
  ~~~~~~~~~~~~~~~~~~~~~~
  GRR currently ships with a sharded SQLite datatbase that is used by default, and a MySQL Advanced datastore that may be a better choice if you have significant in-house MySQL experience and resources.
  
  Performance
  -----------
  
  GRR is designed to scale linearly, but performance depends significantly on the datastore
  implementation, how it is being run, and the hardware it is running on.
  
  Deployment Performance Factors
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  
  The key issue with performance generally relates to how the server is deployed.
  
  - You will probably want to run more than one worker. In a large
    deployment where you are running numerous hunts it makes sense to run 20+
    workers. As long as the datastore scales, the more workers you have the faster
    things get done. We previously had a config setting that forked worker processes off, but this turned out to play badly with datastore connection pools, the stats store, and monitoring ports so it was removed.  We're planning dockerization to make this easier, but for now you should create multiple workers using different init scripts.
  