Hey all, we use hardware loadbalancers that connect to apache to see if the server is still ok. It does not login.
I just realised these do actually create sessions, causing problems with garbage collection :(
select ip,count(ip) from session group by ip order by count desc;
ip | count
-----------------------------------------+------- 194.109.20.222 | 14321 194.109.20.221 | 14295 2001:888:0:22::4 | 4296 2001:888:0:22::3 | 4288
Are connects without login supposed to create a session? If so, why? This is with a relatively recent 0.7 from svn.
Cor
Cor Bosman wrote:
Hey all, we use hardware loadbalancers that connect to apache to see if the server is still ok. It does not login.
I just realised these do actually create sessions, causing problems with garbage collection :(
I'm wondering why these session records cause problems with garbage collection. They do not differ from active session records...
Are connects without login supposed to create a session?
Yes, they are.
If so, why? This is with a relatively recent 0.7 from svn.
For security and performance reasons we only accept login attempts from browsers which have visited the login page before. Therefore a session record is created when a user opens the login page and a 'temp' flag is saved in order to check, whether the user is coming from the login page. Only if that is set, we forward the login attempt to the IMAP backend to authenticate.
That design was there right from the beginning and it seems to work well with default garbage collection settings. Check the 'session_lifetime' config setting in Roundcube. That controls the garbage collection together with PHP's session.gc_* settings.
~Thomas
On Oct 3, 2012, at 10:05 AM, Thomas Bruederli thomas@roundcube.net wrote:
Cor Bosman wrote:
Hey all, we use hardware loadbalancers that connect to apache to see if the server is still ok. It does not login.
I just realised these do actually create sessions, causing problems with garbage collection :(
I'm wondering why these session records cause problems with garbage collection. They do not differ from active session records.
All our servers (15) are behind a loadbalancer that checks if a server is working by connecting to 443. This immediately creates a session. This happens every 5 seconds. Times 15. In 2 hours (our gc time) that creates over 20.000 redundant sessions.
But ive worked around this by pointing our loadbalancers to a custom url inside the roundcube doctree. Problem solved.
Cor
Le 03/10/2012 10:30, Cor Bosman a écrit :
All our servers (15) are behind a loadbalancer that checks if a server is working by connecting to 443. This immediately creates a session. This happens every 5 seconds. Times 15. In 2 hours (our gc time) that creates over 20.000 redundant sessions.
But ive worked around this by pointing our loadbalancers to a custom url inside the roundcube doctree. Problem solved.
Well, the best way will probably be to have a roundcube monitoring page testing the whole chain (web server, php execution, database backend and imap backend) that your loadbalancer could check. This will assure that everything is working fine and not just apache is working. Right now, you can have a server not reaching the database or imap backend for whatever reason and have your loadbalancer not detecting it and leaving it receiving requests.
But I'm not aware of such a test page in roundcube (if someone can implement it, it would be an improvement for large installations).
regards,
S.B.
-
Cor Bosman -
Sébastien BLAISOT -
Thomas Bruederli