Thanks for the pointer, but so fat I see no performance degradation I'll optimize things as soon as any issues will arise
currently flash room is unable to hold more than 10 people (according to one of the user report) On Sun, Aug 21, 2016 at 8:35 AM, [email protected] < [email protected]> wrote: > Hi Maxim, > > I have seen an example where we store the firstname/lastname in the > database instead of the session of the "Client". > > RoomClientPanel.java::43 > > User u = getBean(UserDao.class).get(c.getUserId()); > > Just please keep in mind that access the database is always expensive. > It's not really suited for our real-time communication conference room. For > instance if there are 500 users in a room you have 500 times a select > user.* from users where id = xyz. And that is for every user that enters > the room. > > So 5 users entering with 500 users in the room = 5x500 = 2500 select > queries. > > 100 users entering with 200 users in the room = 100 x 200 = 20000 > selection queries. > > Just for entering the room. > > It's just like one of those lessons learnt from past OpenMeetings > implementations: > Do not access the database during the real-time communication part of a > conference room. It just doesn't scale. > Session vars should be really in the session, not in the database. > > But it's really more generic: The real-time communication tasks like: > userlist, activities, whiteboard events => There should be really no link > from those components into the Database. And if so you have to be really > careful to make it not interrupting, async and the impact of scaling with > 500++ users in a conference room. > > Thanks, > Sebastian > > -- > Sebastian Wagner > https://twitter.com/#!/dead_lock > [email protected] > -- WBR Maxim aka solomax
