With this changelog we introduce a couple of non-default, experimental features. As they are experimental, these features will only be made available on request.
Redis for sessions
Every Hypernode ships with a Redis instance, intended for cache usage. Currently we have disabled the ability to save its data to disk, making it entirely an in-memory key-value store.
Challenges
Several Magento shop owners are interested in using Redis for sessions as well. But putting sessions on the filesystem is not always reliable and it doesn’t scale well and putting them in MySQL may slow down a shop or might cause issues with transactions and deadlocks.
Our solution
With this in mind, we’re currently looking into adding a second Redis instance more tailored towards this use case.
Once enabled, you will have an extra Redis instance listening on port 6378 (instead of the default 6379). Because of the extra memory usage involved with an extra Redis instance, we’ll cut the max memory usage of both your Redis instances in half. Please take this in mind because you might see your cache invalidated faster than before.
Other than trying to save data to disk when restarting, you (read: your application) should persist data to disk when necessary. This is done with the BGSAVE command. For example, to save Redis data to disk every 60 seconds, add this cronjob:
* * * * * redis-cli -p 6378 bgsave
If you’re running Magento 2, there is official documentation on how to set it up to use Redis for sessions. The only thing you should need to configure is session-save-redis-port.
New Relic plugin performance tweaks on Hypernodes booted at Amazon (AWS)
Recently we discovered that the combination of AWS Hypernodes and the New Relic plugin may cause slowdown, especially in peak traffic.
In order to measure the time your application spends in different states, New Relic makes a lot of gettimeofday system calls. These calls are usually super fast, but because of the virtualization technology AWS uses (Xen) they’re a bit slower than you’d normally expect, which adds up quickly when doing hundreds of calls per second – which is exactly what New Relic does.
There is nothing inherently wrong with this, it’s definitely not a bug or a result of poor programming, it’s just an unfortunate combination of two things causing a drop in performance.
Our solution
One solution to this is to not rely on Xen’s system clock but instead rely on the clock built-in to the virtual machine itself. This might have a slight impact in terms of time accuracy, but according to our knowledge is will not have a significant negative effect on applications running on your Hypernode.
Currently we are evaluating this change for performance. If this tweak turns out to be a good solution to the above issue, it will be enabled on all relevant Hypernodes by default in the future. Update: It currently is enabled by default
Interested?
Please contact our support department if you would like to enable either of these features.