例如前台提交用户需要进行渲染的图片，由Gearman调度到后台提供渲染服务的工作进程，在完成工作后返回结果给前台进行展示。提交工作和完成工作的代码只需要通过预先协商好的参数格式进行交互，具体任务的调度、负载均衡、可靠性等，由Gearman服务器来确保。而针对大规模应用，可以很容易进行多路节点的集群部署。

在正式对外发布后，Danga Interactive用C重写了整个服务器代码，支持PHP, Perl, Python等常见脚本客户端，支持用memcached, sqlite, postgresql, tokyocabinet等作为任务持久化队列，基本上来说是便宜量又足。

线程模型

在大规模使用的时候，需要针对应用类型进行参数设置，以使Gearman的性能达到最优，这首先应该了解Gearman的线程模型。

为确保具备对海量任务调度的支持能力，Gearman毫无悬念的选择libevent作为网络操作支撑库。因此Gearman的服务器Gearmand提供了三类线程角色：

端口监听和管理线程，接受新连接请求并将之交给IO线程，1个

IO线程，完成实际的任务处理，包括命令解析，队列操作等，n个

处理线程，完成内部数据结构的管理，无系统调用尽可能简单，1个

其中第1, 3种线程对全局处理性能没有直接影响，虽然处理线程有可能成为瓶颈，但他的工作足够简单消耗可忽略不计，因此我们的性能调优主要目标是在IO线程的数量。
对每个IO线程来说，它都会有一个libevent的实例；所有Gearman的操作会以异步任务方式提交到处理线程，并由IO线程获取完成实际操作，因此IO线程的数量是与可并行处理任务数成正比。Gearmand 提供 -t 参数调整总IO线程数，需要使用 libevent 1.4 以上版本提供多线程支持。

进程句柄数

另外一个影响大规模部署的是进程句柄数，Gearman会为每一个注册的Worker分配一个fd(文件描述符)，而这个fd的总数是受用户限制的，可以使用 ulimit -n 命令查看当前限制

flier@debian:~$ ulimit -n
1024
flier@debian:~$ ulimit -HSn 4096 // 设置进程句柄数的最大软硬限制
4096

也就是说gearman缺省配置下，最多允许同时有小于1024个worker注册上来，fd用完之后的Worker和Client会出现连接超时或无响应等异常情况。因此，发生类似情况时，我们应首先检查 /proc/[PID]/fd/ 目录下的数量，是否已经超过 ulimit -n 的限制，并根据需要进行调整。而全系统的打开文件设置，可以参考 /proc/sys/fs/file-max 文件，并通过 sysctl -w fs.file-max=[NUM] 进行修改。

flier@debian:~$ cat /proc/sys/fs/file-max
24372
flier@debian:~# sysctl -w fs.file-max=100000
100000

更详细的设置请参考 Linux increase the maximum number of open files or file descriptors。

Gearmand 本身也提供了调整句柄数量限制的功能，启动时则可以通过 –file-descriptors 参数指定，但非特权进程不能设置超过soft limit的数额。

-f, –file-descriptors=FDS Number of file descriptors to allow for the process
(total connections will be slightly less). Default
is max allowed for user.

The soft limit is the value that the kernel enforces for the corresponding resource. The hard limit acts as a
ceiling for the soft limit: an unprivileged process may only set its soft limit to a value in the range from 0
up to the hard limit, and (irreversibly) lower its hard limit. A privileged process (under Linux: one with the
CAP_SYS_RESOURCE capability) may make arbitrary changes to either limit value.

轮询调度

此外，Gearmand 还提供了一些增强任务调度公平性的参数，例如 0.13 里面新增的 round-robin 模式，允许将任务公平的调度到多个 Worker，而不是用缺省按 Worker 注册函数的顺序进行调度，避免工作过于集中在少数设备上。

-R, –round-robin Assign work in round-robin order per
workerconnection. The default is to assign work in
the order of functions added by the worker.

Gearmand 内部通过一个 Worker 队列，在 RR 模式下动态调整 Worker 的调度次序。

  if (server_con->thread->server->flags.round_robin)
  {
    GEARMAN_LIST_DEL(server_con->worker, server_worker, con_)
    _server_con_worker_list_append(server_con->worker_list, server_worker);
    ++server_con->worker_count;
    if (server_con->worker_list == NULL) {
      server_con->worker_list= server_worker;
    }
  }

受限唤醒

而通过 –worker-wakeup 参数，则可以指定收到任务时，需要唤醒多少个 Worker 进行处理，避免在 Worker 数量非常大时，发送大量不必要的 NOOP 报文，试图唤醒所有的 Worker。

-w, –worker-wakeup=WORKERS Number of workers to wakeup for each job received.
The default is to wakeup all available workers.

根据 Gearman 协议设计， Worker 如果发现队列中没有任务需要处理，是可以通过发送 PRE_SLEEP 命令给服务器，告知说自己将进入睡眠状态。在这个状态下，Worker 不会再去主动抓取任务，只有服务器发送 NOOP 命令唤醒后，才会恢复正常的任务抓取和处理流程。因此 Gearmand 在收到任务时，会去尝试唤醒足够的 Worker 来抓取任务；此时如果 Worker 的总数超过可能的任务数，则有可能产生惊群效应。

  /* Queue NOOP for possible sleeping workers. */
  if (job->function->worker_list != NULL)
  {
    worker= job->function->worker_list;
    noop_sent= 0;
    do
    {
      if (worker->con->options & GEARMAN_SERVER_CON_SLEEPING &&
          !(worker->con->options & GEARMAN_SERVER_CON_NOOP_SENT))
      {
        ret= gearman_server_io_packet_add(worker->con, false,
                                          GEARMAN_MAGIC_RESPONSE,
                                          GEARMAN_COMMAND_NOOP, NULL);
        if (ret != GEARMAN_SUCCESS)
          return ret;

        worker->con->options|= GEARMAN_SERVER_CON_NOOP_SENT;
        noop_sent++;
      }

      worker= worker->function_next;
    }
    while (worker != job->function->worker_list &&
           (job->server->worker_wakeup == 0 ||
           noop_sent < job->server->worker_wakeup));

    job->function->worker_list= worker;
  }

除此之外，针对应用特点合理使用持久化队列，在大并发任务量的情况下对性能也会有直接影响。

归根结底，需要根据自己的应用场景，合理设计一些测试用例和自动化脚本，通过实际的运行状态进行参数调整。