[Building Sakai] Sakai 2.9.2 and Kernel 1.3.2 problems during load testing

[Steve Swinsburg]

Hi Chuck,

Do we even need a cache on this? As you say, how often does a site change its frame policy? They might change it once or twice only. Having it refresh its cache regularly and perform all of that work for something that will rarely, if ever occur is unnecessary IMO. It's nice for automation but maybe not as useful in this case.

I'd scrap the cache and just have it refresh its setting when the iframe portlet settings are saved. Then if the other site does change their settings, a user can go and update the settings and it will be fixed.  Then it may never need to be updated ever again. There may be a downtime when the link is not available and until someone can fix it. But there will be during the cache period also. And it would be a rare occurrence anyway.

cheers,
S



On 07/08/2013, at 10:51 PM, Charles Severance <csev at umich.edu> wrote:

> 
> On Aug 6, 2013, at 9:55 AM, "Kusnetz, Jeremy" <JKusnetz at APUS.EDU> wrote:
> 
>> The graphs are a little misleading.  We upgraded to 2.9.x on an off week so we had lower usage anyway.
>>  
>> Yesterday was a semester start for us, we logged 62,088 site.upd events for the day.  Our last semester start last month which has very similar number of users and usage we saw 8,452 site.upd events.  So a bit more than 7x the number of site.upd events in 2.9.x.
> 
> Thanks - that makes more sense.   
> 
> With the new iframe xframe processing we should expect more site.upd events.   But not a massive number because the results are cached for two hours by default and it is a value you can set.   So for every active web content tool,during a day - you can expect one *additional* site.upd event caused by a view every two hours.
> 
> Now because I missed a detail (not exactly a bug :) ) - A default-configured "Home" tool is running this xframe check when it should not be running the check.  Everything works and the Home tool caches its xframe results properly for two hours - but for a Home tool with a default configuration it should not be doing an xframe check at all.
> 
> So when I fix
> 
> https://jira.sakaiproject.org/browse/SAK-23841
> 
> It should eliminate (a) all the site.upd events from unconfigured Home tools and eliminated site.upd events for web content tools from the same host as Sakai is running on.   So they should drop - depending on whether you are running a load test (all home tools unconfigured) or real user load with lots of home tools reconfigured - the expected drop in site.upd events can range anywhere from eliminating 3/4 of the new events to about 1/4 of the new events.   The events will not go away after SAK-23841 - they will will not be so many un-needed events.
> 
> And you canfurther reduce the number of events by setting the cache time to be something like 6 hours.   How often does a site change its xframe policy ?  We could even decude that the right default should be six hours with a little more experience.   I would like ot fist fix SAK-23841 and see the effect that has both on load test scenarios (which I expect to be very significant) and normal usage scenarios.
> 
> Thanks for the investigation on this.   It is good to figure out the subtle tweaks needed to this feature.  The feature is increasingly important for end-user usability - but we need to get it right.
> 
> I expect to have a patch/fix by the end of the week. 
> 
> Make sense?
> 
> /Chuck
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> 
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20130807/20773e4e/attachment.html