How to optimize GNU Social/postActiv

postActiv optimization

Often times people tend to complain that their instance is running slow for some reason. Many factors can contribute to this, but often times a lot of the speed and response issues can be resolved by tuning some settings.

Note: These optimizations assume you have shell access.

1. Disable schema check on pageload

If you're using postActiv you won't need to do this since it's disabled by default. If you use GNU Social though, you'll need to do a small change.

Uncomment the following line in config.php:

//$config['db']['schemacheck'] = 'script';

Note that you will need to execute scripts/checkschema.php whenever you install or update a plugin.

2. Tune the web server

Enabling things like gzip compression, tuning the SSL ciphers allowed, etc. can help load times by a lot. However, I won't be convering how to do it here since there's a lot of different server configurations and it's not hard to search up "gzip compression [server software]" in your favourite search engine.

3. Enabling queue daemons

By default, both GNU Social and postActiv use the Opportunistic Queue Manager which handles background tasks with each pageload. This works fine on a small instance, but doesn't scale well. Here instead, we'll delegate this to dedicated background processes.

The queue daemons are flexible with regards to being able to use various backends. The easiest to use is the MySQL-backed queue, but it's not tuned specifically for that kind of workload. Instead, you should use the RabbitMQ backend, which there exists a pretty good guide for setting up one. If you use postActiv, you can opt to use Redis instead using a previous guide I wrote.


This is not the be-all-end-all guide, but its a good starting point for tuning a GNU Social/postActiv install so that it can scale and be more responsive. There's advanced stuff like tuning MySQL and whatnot, but these steps can help get you most of the way there.