Comparing latency with redis-cli I found out that I have 8000 microseconds latency with TCP and half of that(!) 4000 microseconds with a UNIX socket (LXC on a KVM VPS with dedicated resources). And Till Krüss Object Cache supports it very well. So my proposed changes as a pull request on GitHub https://github.com/QROkes/webinoly/pull/41.
Also here a script that I use to disable transparent hugepages persistently to further improve Redis latency on my host:
#!/bin/bash cat > /usr/local/bin/disable-tph.sh <<EOF#!/bin/bashecho never > /sys/kernel/mm/transparent_hugepage/enabledecho never > /sys/kernel/mm/transparent_hugepage/defragEOF chmod u+x /usr/local/bin/disable-tph.sh cat > /etc/systemd/system/disable-thp.service <<EOF[Unit]Description=Disable Transparent Hugepages[Service]ExecStart=/usr/local/bin/disable-tph.sh[Install]WantedBy=multi-user.targetEOF sudo systemctl start disable-tphsudo systemctl enable disable-tph
cat > /usr/local/bin/disable-tph.sh <<EOF
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
chmod u+x /usr/local/bin/disable-tph.sh
cat > /etc/systemd/system/disable-thp.service <<EOF
Description=Disable Transparent Hugepages
sudo systemctl start disable-tph
sudo systemctl enable disable-tph
Do you have any technical references or docs to support these improvements?
Yes, here some references:
My own testing confirmed the 50% on a virtualized environment (with redis-cli --intrinsic-latency 100). Also with the wp-config additions Till Krüss's Object Cache connected wonderfully with redis over the socket, without testing I would not have made the suggestion. I did not do a long turn test though, but I do not expect any problems.
The TCP vs Sockets is an old discusion that always ends up in the same conclusion: "Under certain conditions one is better than the other"
I will consider it in the future, it's not a priority, also following this logic we will need to change the php-fpm connection too.
Seems like it's the same case for Transparent Hugepages, it's good for some things and bad for anothers.
Regarding transparent hugepages people seem to be unanimous, it is not a question if it should be turned off:
Thanks for considering the sockets (of course you are right, in my virtualized case it showed good results, but they are microseconds after all...).And you are right, according to this explanation a socket for both php-fpm and redis would make sense: https://stackoverflow.com/questions/42704763/what-are-the-differences-from-running-php-fpm-over-an-unix-socket-vs-a-tcp-ip-so
Who'd know better than the redis people?
Couldn't agree more! The thing is that Webinoly is not a Redis server and we don't know what will be the impact on the whole web server. I'm just saying that we need to do a little more research before making a decision in this regard.
Sounds good, once I find some time I'll try to run a site longer on sockets, both php-fpm and redis. But for now I will concentrate on other things.
I am definitely turning off transparent hugepages on my host server, will let you know if there are any problems after some time.
Your regular donations is what keep this project moving forward. If you like Webinoly, buy me a coffee or a beer to show support.