AnyEvent-Fork-Pool
view release on metacpan or search on metacpan
Creates a new pool object with the specified $function as function
(name) to call for each request. The pool uses the $fork object as
the template when creating worker processes.
You can supply your own template process, or tell
"AnyEvent::Fork::Pool" to create one.
A relatively large number of key/value pairs can be specified to
influence the behaviour. They are grouped into the categories "pool
management", "template process" and "rpc parameters".
Pool Management
The pool consists of a certain number of worker processes. These
options decide how many of these processes exist and when they
are started and stopped.
The worker pool is dynamically resized, according to (perceived
:) load. The minimum size is given by the "idle" parameter and
the maximum size is given by the "max" parameter. A new worker
is started every "start" seconds at most, and an idle worker is
stopped at most every "stop" second.
You can specify the amount of jobs sent to a worker concurrently
using the "load" parameter.
idle => $count (default: 0)
The minimum amount of idle processes in the pool - when
there are fewer than this many idle workers,
"AnyEvent::Fork::Pool" will try to start new ones, subject
to the limits set by "max" and "start".
This is also the initial amount of workers in the pool. The
default of zero means that the pool starts empty and can
shrink back to zero workers over time.
max => $count (default: 4)
The maximum number of processes in the pool, in addition to
the template process. "AnyEvent::Fork::Pool" will never have
more than this number of worker processes, although there
can be more temporarily when a worker is shut down and
hasn't exited yet.
load => $count (default: 2)
The maximum number of concurrent jobs sent to a single
worker process.
Jobs that cannot be sent to a worker immediately (because
all workers are busy) will be queued until a worker is
available.
Setting this low improves latency. For example, at 1, every
job that is sent to a worker is sent to a completely idle
worker that doesn't run any other jobs. The downside is that
throughput is reduced - a worker that finishes a job needs
to wait for a new job from the parent.
The default of 2 is usually a good compromise.
start => $seconds (default: 0.1)
When there are fewer than "idle" workers (or all workers are
completely busy), then a timer is started. If the timer
elapses and there are still jobs that cannot be queued to a
worker, a new worker is started.
This sets the minimum time that all workers must be busy
before a new worker is started. Or, put differently, the
minimum delay between starting new workers.
The delay is small by default, which means new workers will
be started relatively quickly. A delay of 0 is possible, and
ensures that the pool will grow as quickly as possible under
load.
Non-zero values are useful to avoid "exploding" a pool
because a lot of jobs are queued in an instant.
Higher values are often useful to improve efficiency at the
cost of latency - when fewer processes can do the job over
time, starting more and more is not necessarily going to
help.
stop => $seconds (default: 10)
When a worker has no jobs to execute it becomes idle. An
idle worker that hasn't executed a job within this amount of
time will be stopped, unless the other parameters say
otherwise.
Setting this to a very high value means that workers stay
around longer, even when they have nothing to do, which can
be good as they don't have to be started on the netx load
spike again.
Setting this to a lower value can be useful to avoid memory
or simply process table wastage.
Usually, setting this to a time longer than the time between
load spikes is best - if you expect a lot of requests every
minute and little work in between, setting this to longer
than a minute avoids having to stop and start workers. On
the other hand, you have to ask yourself if letting workers
run idle is a good use of your resources. Try to find a good
balance between resource usage of your workers and the time
to start new workers - the processes created by
AnyEvent::Fork itself is fats at creating workers while not
using much memory for them, so most of the overhead is
likely from your own code.
on_destroy => $callback->() (default: none)
When a pool object goes out of scope, the outstanding
requests are still handled till completion. Only after
handling all jobs will the workers be destroyed (and also
the template process if it isn't referenced otherwise).
To find out when a pool *really* has finished its work, you
can set this callback, which will be called when the pool
has been destroyed.
AnyEvent::Fork::RPC Parameters
These parameters are all passed more or less directly to
AnyEvent::Fork::RPC. They are only briefly mentioned here, for
their full documentation please refer to the AnyEvent::Fork::RPC
( run in 1.375 second using v1.01-cache-2.11-cpan-39bf76dae61 )