Walid MOGHRABI
2018-08-13 10:49:15 UTC
package: x2gobroker
version: 0.0.4.0-0~1038~ubuntu16.04.1
priority: enhancement
I'm not really sure of that because it is pretty hard to reproduce that one but I have the impression that, if you have many users connecting nearly at the same time (and especially within the loadchecker sleep time which is 300s by default), the load factor value is not recalculated and thus, you might have many users sent to the same server instead of beeing equally distributed of the farm.
Sometime, I have 3, 4, 5 ... users sent to the same server while I have a few servers empty of connected users.
This is a race condition but every morning, it can happen since our users starts between 8:30AM and 9:30AM and we have about 100 users so you can easily have 5~6 people connecting in less than a minute.
I think the load calculation should be more dynamic and not strictly done every x minutes.
For example, you can still do the load calculation every 5mn in order to "reset" load values once but then, I think something like this could be done :
* calculate the load every x minutes ("bootstrap" calculation)
* user A logging in, broker asks loadchecker for a server to connect the user, loadchecker respond "server-01"
* user A is sent to "server-01" and then, "server-01" is locked for a few seconds (5, 10, ... maybe user defined) (blocked for new incoming connections)
* broker asks loadchecker to re-calculate the load value for "server-01" only
* "server-01" is unlocked for new incoming connections
That way, load value is recalculated "on demand" in real time and connections are sure to be retargeted to more available servers while this calculation is done.
---
DISCLAIMER: This e-mail is private and confidential and may contain proprietary or legally privileged information. It is for the intended recipient only. If you have received this email in error, please notify the author by replying to it and then destroy it. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail or any attachment. Thank you
version: 0.0.4.0-0~1038~ubuntu16.04.1
priority: enhancement
I'm not really sure of that because it is pretty hard to reproduce that one but I have the impression that, if you have many users connecting nearly at the same time (and especially within the loadchecker sleep time which is 300s by default), the load factor value is not recalculated and thus, you might have many users sent to the same server instead of beeing equally distributed of the farm.
Sometime, I have 3, 4, 5 ... users sent to the same server while I have a few servers empty of connected users.
This is a race condition but every morning, it can happen since our users starts between 8:30AM and 9:30AM and we have about 100 users so you can easily have 5~6 people connecting in less than a minute.
I think the load calculation should be more dynamic and not strictly done every x minutes.
For example, you can still do the load calculation every 5mn in order to "reset" load values once but then, I think something like this could be done :
* calculate the load every x minutes ("bootstrap" calculation)
* user A logging in, broker asks loadchecker for a server to connect the user, loadchecker respond "server-01"
* user A is sent to "server-01" and then, "server-01" is locked for a few seconds (5, 10, ... maybe user defined) (blocked for new incoming connections)
* broker asks loadchecker to re-calculate the load value for "server-01" only
* "server-01" is unlocked for new incoming connections
That way, load value is recalculated "on demand" in real time and connections are sure to be retargeted to more available servers while this calculation is done.
---
DISCLAIMER: This e-mail is private and confidential and may contain proprietary or legally privileged information. It is for the intended recipient only. If you have received this email in error, please notify the author by replying to it and then destroy it. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail or any attachment. Thank you