Activating Warp Speed for Hubzilla's Database

  zuletzt bearbeitet: Sat, 26 Jan 2019 11:04:15 +0100  
How to significantly gain speed and perfomance for Hubzilla by just some minor adjustments.
Note: The DB section is about MySQL/MariaDB. However, PostgresQL will be similar effected. The solultion is database agnostic.
Artikel ansehen
File based session handling
Store your sessions in files residing  /tmp. Some time ago this was considered to be a bad/slow solution (after all, a database is faster, eh?) However, tmp now usually has got tmpfs as a filesystem, which means /tmp is a RAM disk, which is much, much faster than a database. (If your tmp is not having a tmpfs, try the other option). There are two caveats, though: When the machine where your PHP interpreter (either fpm or mod_php) runs on has to reboot (either due to planned maintenance or powerloss) the sessions will be gone, the users will have to log in again That's an acceptable price to pay. The second one concerns scaling issue: If you run a high-performance setup (i.e. load balancer, more than one webserver) this can't be used since all application servers have to access the shared sessions.
External session storage
You run a small key/value in-memory database on another host. The usual ones are memcache or Redis (I myself haven't got mixed experiences with Redis as as session store, but your mileage may vary). All application servers (Apache with PHP) can access the storage, so this is the way to go if you have more than one application server. If you use Redis, the session can also be saved in regular intervals on the disk, therefore you won't lose the sessions if your session storage goes down (reboot, update, whatver), however you will lose some speed advantage. I myself would recommend memcache, it's blazingly fast and stores the session ony in memory, but feel free to toy with Redis.

Setting it up in Hubzilla

Unfortunately Hubzilla doesn't support changing the session handler out of the box. I've written a small patch (which I will submit for review) to enable ist (it's attached to this article):
cd <your instance>/Zotlabs/Web
(copy Session.patch here)
patch < Session.patch

After that you can switch the session handler, by default it's still database, so the patch won't do any harm. If you want to change the handler change .htconfig.php in Hubzilla's base directory:
App::$config["system"]['session_custom'] = true;
App::$config["system"]['session_save_handler'] = "files";
App::$config["system"]['session_save_path'] = "/tmp"

(Or whatever you prefer - memcached, redis,..)

After that all your former sessions will be unavailabe, i.e. users have to login again (including nomad's users), but after that things run rather smoothly.

About the performance gain

In my case it's hard to say, because the ssd is so fast - still the graph seems to indicate that even on a fast ssd (4 cores, 16 GB Ram, 10 GB Innodb buffer pool) there is a perfomance gain. I'd love to see if someone tries this on a slow machine - how much perfomance did you gain? I'd really be interested in feedback.


By changing Hubzilla's session handling one can gain a significant perfomance boost - the only disadvantage is that the sessions may be a little bit volatile (i.e. not reboot safe), but that's a small price to pay.

Edit 2019-01-26

I've expanded the patch making it possible to change session.gc_probability and session.gc_divisor (defaulting to 1 and 100 for custom session handlers):

App::$config["system"]['session_gc_probability'] = 1;
App::$config["system"]['session_gc_divisor'] = 100;

i like the idea. a little volatility in session management really is a small price to pay. how often do webservers go down, and most everyone will have their browsers 'remember' login/pwd for a frequently used site like hubzilla.

why don't you !-add this to @Hubzilla Development so that others can give their input? i don't think everyone who might have something to say follows the framagit issues...