Yeah I understand this problem - but this is another one I guess.
As we watch the balancer creating meetings on servers that already have
a big load (cpu) because it only looks on the meeting count.
so this is not specific to universities - the balancing at all is not
very useful as the meetings do not matter at all. You could have 50
meetings on a server and will not have a problem if only 2 users are in
every meeting.
scalelite would not allow that ... meetings can be used but should not
be the first source for the balancer.
the first should be video as this is the one that mostly would crash if
there are to many on one server. second should be users and third the
meetings.
of course the balancer would not know how many may join in the next
minutes and would create to many meetings on this server if other
servers also are used already, but if the balancer uses some simple
rules it could be improved a lot:
1. use empty servers first.
2. use servers with less users and less video.
3. use servers with less video
this would prevent such cases.
aditionally the server / balancer should ignore breakout rooms. right
now a server with one meeting and 5 users e.g. would not be used anymore
if they open 4 breakout rooms as the server thinks there are 5 meetings
on it.
Hope this can be evaluated and be changed in an upcoming update - as it
really is simple to change and would help many people out there.
of course the calculation could be made more efficient and intelligent,
but just taking users and video into account before having a look at the
count of meetings would already improve it.
cheers
Martin
Am 14.10.2020 um 16:36 schrieb sd...@distancelearning.cloud:
> Yes, that’s the problem... in real world scaling for universities you
> get a surge of meeting starts 10-15minutes before the hour when
> teachers are getting ready for next class.... the classes for the
> previous hour are all still mostly running at 45past so you have this
> period where meetings from both hours need to be running.
>
> So if you have needs for 100 concurrent classes, you really need to
> provision 125-150 slots for meetings. Since the overlap oversubscribes
> your hardware, and create some bad experiences.
>
> In a telco application, where meetings are started anytime of day,
> vary in length and size, and at any interval the load is spread more
> evenly, but you need to plan for the peak in case everyone wants a 9am
> Monday morning.. so autoscaling a must.
>
> So its hard to efficiently balance without these extra inputs.. number
> meetings works bests, but requires a lot more heavy metal.