@tsteur opened this Issue on December 3rd 2014 Member

I think it makes sense to offer the possibility to use Redis to manage sessions as mentioned in #6637 and later by another user in #6075. Redis is just perfect for storing sessions when using multiple frontend nodes as an alternative to database. All operations are performed in memory making reads and writes blazing fast.

It is very easy to configure in case the Redis extension phpredis is installed which is required for Queued Tracking #6075 anyway.

session.save_handler = redis 
session.save_path    = tcp://127.0.0.1:6379  // I think multiple servers can be configured comma separated
@tsteur commented on December 4th 2014 Member

I noticed this is already possible to do by setting the following save_handler in config.ini.php

[General]
session_save_handler = ""

and in php.ini configure the save_handler manually as mentioned above eg.

[Session]
session.save_handler = redis
session.save_path = tcp://127.0.0.1:6379

How could we better promote this for "clusters" (using multiple front nodes)? I also worked for 15 min on a plugin and it would be easily doable to write a simple plugin for this as well. Would be maybe the best / easiest way to promote this kind of session handler to show how other people could add their own session handlers?

@mattab commented on December 7th 2014 Member

For most people the database session handler is enough I think. I guess redis session handler will be most useful for power users like InnoCraft who use redis also for the tracker API via https://github.com/piwik/plugin-QueuedTracking

Therefore maybe it'd be enough to document it in a new FAQ similar to that one.. and link it from there, and from this one. thoughts?

@trucleavinetworks commented on December 8th 2014

Hi, I didn't mean that we use Redis for frontend admin session.
My idea is when tracker records the log file into database, tracker query the database to get session data from log_visit and log_link_visit_action table.
With redis, we could use expire functionality. But it just set by TTL, with bulk import the time that we actually record might be delayed for hours. So that I used sorted set and periodically expire old sesion data.
This is about how to use redis to increase the performance (reduce database track loading).

@mattab commented on December 8th 2014 Member

@trucleavinetworks you make a good point, maybe we could use Redis to cache the visitors in the last window_look_back_for_visitor and this could bring performance to the importing process. but i'm not sure if there is big need for this change (because it's quite complex one and maybe there are other improvements we could make?)

@tsteur commented on December 9th 2014 Member

It should be at least recommended in an article where it is described how to setup "Piwik with multiple front nodes" and in case there is an article "Piwik high performance" as it is good to use it even when not using QueuedTracking. Should be also mentioned as you said where "setup alternative to file sessions".

I'd have a plugin here that I developed quickly as mentioned and it works. Only problem that I didn't solve was to restore the original session handler again in case someone wants to disable the plugin again. But do not plan to release it for now. Waiting for #6609 . Otherwise if someone enters a wrong save path in "Plugin Settings" it would be no longer able to access Piwik I think. In case someone is interested in the code ping me.

@mattab commented on April 25th 2015 Member

this new features will be documented as a FAQ in #7767

This Issue was closed on April 25th 2015
Powered by GitHub Issue Mirror