The Zerg mode (uWSGI 0.9.8.1)

(yes it is Zerg as the Starcraft race, so if you are not a starcraft player be prepared to some "nonsense" ;)

When your site load is variable, you would be able to add workers dinamically.

You can obviously edit your conf and reload your uWSGI instance, but for very loaded apps this is undesiderable.

Enabling zerg mode, you will allow "uwsgi-zerg" instances to attach to your already running server and help it in the work.

Zerg-mode is obviously local-only, you cannot use it to add remote instances (this is a job done by the fastrouter, the http plugin or your webserver load balancer).

Enabling the zerg server

If you want a uWSGi instance to be rushed by zerg you have to enable the zerg server. It will be bound to a unix socket and will pass uwsgi sockets file descriptors to the zerg connecting to it.

For security reason the unix socket does not inherit the --chmod-socket option, but will always use the current umask. If you have filesystem permissions issues, on Linux, you can use the UNIX sockets in abstract namespace (simply prepend @ to the socketname)

• a normal unix socket

./uwsgi -M -p 8 --module welcome --zerg-server /var/run/mutalisk

• linux abstract namespace

./uwsgi -M -p 8 --module welcome --zerg-server @nydus

Attaching zergs to the zerg server

To add a new instance to your zerg pool, simply use the --zerg option

./uwsgi --zerg /var/run/mutalisk --master --processes 4 --module welcome

In this way 4 new workers will start serving requests.

When your load come back to normal values, you can simply shutdown all of the uwsgi-zerg instances without problems.

You can attach an unlimited number of uwsgi-zerg instances.

fallback if a zerg server is not available

By default a zerg client will not run if a zerg server is not available. That means: if your zerg-server dies, and you reload your zerg client, it will simply shutdown.

if you want to avoid that behaviour, add at least a --socket directive mapping to the required socket (the one that should be managed by the zerg server) and add --zerg-fallback option

With this setup if a zerg server is not available, the zerg client will continue binding normally to the specified socket/sockets.

Using zerg as testers

A good trick you can use, is suspending the main instace (with SIGTSTOP) and load the new app version in a zerg. If the code is not ok you can simply shutdown the zerg and resume the main instance.

The ZergPool

zergpools are special zerg servers. They only serve zerg clients. nothing more.

You can use them to build high-availability systems reducing downtime during tests/reloads.

You can run an unlimited number of zergpools (on various unix sockets) and map an unlimited number of sockets to them

[uwsgi]
master = true
zergpool = /tmp/zergpool_1:127.0.0.1:3031,127.0.0.1:3032
zergpool = /tmp/zergpool_2:192.168.173.22:3031,192.168.173.22:3032

with this config you will have two zergpools each one serving two sockets.

You can now attach instances to them

uwsgi --zerg /tmp/zergpool_1 --wsgi-file myapp.wsgi --master --processes 8

uwsgi --zerg /tmp/zergpool_2 --rails /var/www/myapp --master --processes 4

You can attach a single instance to multiple zerg servers

uwsgi --zerg /tmp/zergpool_1 --zerg /tmp/zergpool_2 --wsgi-file myapp.wsgi --master --processes 8