[CalendarServer-changes] [8982] CalendarServer/trunk/doc/Admin/LoadSimulation.txt

Wed Apr 4 15:37:43 PDT 2012

Revision: 8982
          http://trac.macosforge.org/projects/calendarserver/changeset/8982
Author:   dre at apple.com
Date:     2012-04-04 15:37:43 -0700 (Wed, 04 Apr 2012)
Log Message:
-----------
Adding sim workers does not affect the amount of work attempted; rather, more workers allows you to reach a higher maximum workload, because work is distributed evenly across the workers

Modified Paths:
--------------
    CalendarServer/trunk/doc/Admin/LoadSimulation.txt

Modified: CalendarServer/trunk/doc/Admin/LoadSimulation.txt
===================================================================

--- CalendarServer/trunk/doc/Admin/LoadSimulation.txt	2012-04-04 22:14:54 UTC (rev 8981)
+++ CalendarServer/trunk/doc/Admin/LoadSimulation.txt	2012-04-04 22:37:43 UTC (rev 8982)
@@ -289,9 +289,9 @@
 Scalability
 ---------------------
 
-A good amount of activity can be generated by a single client sim instance, and that should be suitable for most cases. However, if your task is performance or scalability testing, you will likely want to use more than a single CPU core to generate the workload. By adding a 'workers' key to the sim's config file you can specify the use of additional instances on the local host, and / or remote hosts.
+A good amount of activity can be generated by a single client sim instance, and that should be suitable for most cases. However, if your task is performance or scalability testing, you will likely want to generate more load than can be presented by a single CPU core (which is all you can get from a single Python process). By adding a 'workers' array to the sim's config file you can specify the use of additional sim instances on the local host, and / or remote hosts. In this configuration, the master process will distribute work across all the workers. In general, you shouldn't need additional workers unless you are approaching CPU saturation for your existing sim instance(s). The "lag" statistic is another useful metric for determining whether the client sim is hitting its targets - if it gets too high, consider adding workers.
 
-The specific approach you take when configuring a high load depends on your goals and available resources. If your goal is to beat down a server until it melts into the floor, it is legitimate to use a less 'accurate' simulation by reducing the timers and intervals in the client sim's behavior configuration. If instead you wish to see how many 'accurate' clients your server can service, you will want to stick with reasonable values for timers and intervals, and instead increase load by using larger numbers of clients (in the 'arrival' config), and / or running additional instances. This tradeoff might be summarized: accuracy vs file descriptors.
+The specific approach you take when configuring a high load depends on your goals and available resources. If your goal is to beat down a server until it melts into the floor, it is legitimate to use a less accurate simulation by reducing the timers and intervals in the client sim's behavior configuration. If instead you wish to see how many 'realistic' clients your server can service, you will want to stick with reasonable values for timers and intervals, and instead increase load by configuring more user accounts (in the 'arrival' section of the config file, and the separate user accounts file).
 
 To use four instances on the local host::
 
@@ -319,7 +319,7 @@
 
 **When using remote hosts, the ssh commands must work in an unattended fashion, so configure SSH keys as needed**. Also, each remote host needs to have a Calendar Server SVN checkout. In this example, the hosts blade2 and blade3 need to have an SVN checkout of Calendar Server at ~/ccs/CalendarServer.
 
-Configuration of the additional workers is handled by the master, so you need not distribute the sim's config file to the other hosts. Each instance gets an identical copy of the config, so the overall load presented to the server scales linearly with the number of workers. Two workers present twice as much load as one worker, assuming they both are reporting sufficiently low 'lag' values.
+Configuration of the additional workers is handled by the master, so you need not distribute the sim's config file to the other hosts. Each instance gets an identical copy of the config. The amount of work attempted by the sim is not changed by adding workers; instead, the master distributes work (i.e. user accounts) across the workers. To do more work, add user accounts.
 
 When running the sim using multiple instances, the standard output of each child instance is sent to the master. For example, when starting with four instances::
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/calendarserver-changes/attachments/20120404/f8731e5b/attachment.html>
