[Building Sakai] production disaster apparently due to chat

[Hedrick Charles]

I've looked, and don't see a significant difference. We did have occasional problems in older versions, when a large class had online office hours. Earlier this week was particularly bad. But also our user's expectations, and how Sakai is used, have changed. We can no longer survive periods of unusably slow response.

On Nov 4, 2011, at 2:24:42 AM, Stephen Marquard wrote:

> Is there something new or different in 2.8 that makes this worse than in 2.7 and earlier?
> 
> Regards
> Stephen
> 
> Stephen Marquard, Acting Director 
> Centre for Educational Technology, University of Cape Town
> http://www.cet.uct.ac.za
> Email/IM/XMPP: stephen.marquard at uct.ac.za 
> Phone: +27-21-650-5037 Cell: +27-83-500-5290 
> 
> 
> 
>>>> Hedrick Charles <hedrick at rutgers.edu> 11/4/2011 2:31 AM >>>
> If you're right, than my latest code may be about right, except that it might be worth evicting the messages. I would never have thought of that. I'm going to deploy the patches from SAK-21353 tomorrow. The original code is pretty clearly a disaster waiting to happen.
> 
> However I agree that a more serious look at the design might produce better results. The delivery object seems to need the address, the text of the message, the author and the date. The ChatMessage object doesn't seem too bad, except maybe for the ChatChannel reference, but hopefully there won't be many different ChatChannel objects. ChatDelivery has a bit more overhead, but it may not be too much.
> 
> I would appreciate it if you'd think about this. Sakai chat is primarily useful for things like online office hours. AIM, Skype, etc, is more interesting for individual communications. In big places like Rutgers, chat is always going to end up being used for very large classes. It's been a continuing source of performance problems. Heaven help us if the whole senior class decide to hold a group chat, which is not impossible… We're starting to see sites created automatically based on LDAP queries. These tend to be things like all majors, all students in a college, etc. I.e. very big memberships.
> 
> 
> 
> 
> 
> ###
> 
> UNIVERSITY OF CAPE TOWN 
> 
> This e-mail is subject to the UCT ICT policies and e-mail disclaimer published on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 21 650 9111. This e-mail is intended only for the person(s) to whom it is addressed. If the e-mail has reached you in error, please notify the author. If you are not the intended recipient of the e-mail you may not use, disclose, copy, redirect or print the content. If this e-mail is not related to the business of UCT it is sent by the sender in the sender's individual capacity.
> 
> ###
>