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

Mon Aug 5 17:02:27 PDT 2013

This feature detects if the remote site has the X-FRAME-OPTION headers and
attempts to cache that value on the tool so it doesn't recheck. This is
done if the popup button is not checked because it means that the site
won't work embedded. I'm guessing the cache is there just in-case this
option changes? There was probably a time when sites with this header set
now didn't have it set in the past, but you wouldn't need to check very
often.

If you set the property Beth mentioned, then it returns false and it
doesn't check/doesn't cache.

On Mon, Aug 5, 2013 at 7:47 PM, Kusnetz, Jeremy <JKusnetz at apus.edu> wrote:

>  We are seeing a much higher increase of that event since upgrading too.
> Can someone tell me what the effect of setting this parameter does?****
>
> ** **
>
> ****
>
> ** **
>
> -----Original Message-----
> From: sakai-dev-bounces at collab.sakaiproject.org [mailto:
> sakai-dev-bounces at collab.sakaiproject.org] On Behalf Of Beth Kirschner
> Sent: Monday, August 05, 2013 5:43 PM
> To: sakai-dev at collab.sakaiproject.org sakai
> Subject: Re: [Building Sakai] Sakai 2.9.2 and Kernel 1.3.2 problems during
> load testing
>
> ** **
>
> We've found the source of the high db cpu load in the web portlet code -
> I've filed the following JIRA:****
>
>                 https://jira.sakaiproject.org/browse/SAK-23841****
>
> ** **
>
> An easy workaround for those who might see this problem is to set the
> following in sakai.properties:****
>
>                 iframe.xframe.cachetime=0 ****
>
> ** **
>
> - Beth****
>
> ** **
>
> On Aug 1, 2013, at 6:02 PM, Steve Swinsburg <steve.swinsburg at gmail.com>
> wrote:****
>
> ** **
>
> > It's possible to restructure that query to give the database a better
> chance at optimising. It joins everything only to discard most of it at the
> end. I know the execution time isn't the real issue but everywhere we can
> optimise for performance we should.****
>
> > ****
>
> > Cheers,****
>
> > S****
>
> > ****
>
> > ****
>
> > ****
>
> > Sent from my iPad****
>
> > ****
>
> > On 02/08/2013, at 6:56, Beth Kirschner <bkirschn at umich.edu> wrote:****
>
> > ****
>
> >> Hi all,****
>
> >> ****
>
> >> We're running load tests against a Sakai 2.9.2 based build, with a few
> kernel patches (mentioned at bottom of email) and seeing a 14 times
> increase with the number of executions of the SAKAI_REALM_FUNCTION query
> below. While we're digging into why, I thought I'd ask this esteemed
> audience if they had any thoughts as to what might be causing this increase.
> ****
>
> >> ****
>
> >> Thanks,****
>
> >> - Beth****
>
> >> ****
>
> >> ### Results from our Sakai 2.9.2 based build:****
>
> >> ****
>
> >>       Elapsed                  Elapsed Time****
>
> >>       Time (s)    Executions  per Exec (s)  %Total   %CPU    %IO    SQL
> Id****
>
> >> ---------------- -------------- ------------- ------ ------ ------
> -------------****
>
> >>        2,676.6        748,379          0.00   17.1   99.5     .0
> 3ryj6azagfbwv****
>
> >> Module: JDBC Thin Client****
>
> >> select DISTINCT FUNCTION_NAME from SAKAI_REALM_FUNCTION SRF inner ****
>
> >> join SAKAI_REA LM_RL_FN SRRF on SRF.FUNCTION_KEY = SRRF.FUNCTION_KEY **
> **
>
> >> inner join SAKAI_REALM_ROL E SRR on SRRF.ROLE_KEY = SRR.ROLE_KEY ****
>
> >> inner join SAKAI_REALM SR on SRRF.REALM_KE Y = SR.REALM_KEY where ****
>
> >> SRR.ROLE_NAME = :1 and SR.REALM_ID IN (:2 ,:3 ,:4 )****
>
> >> ****
>
> >> ****
>
> >> ### Results from our Sakai 2.9.1 based build****
>
> >> ****
>
> >>    176.6       53,040       0.00    1.8      177.6   99.4     .0
> 3ryj6azagfbwv****
>
> >> Module: JDBC Thin Client****
>
> >> select DISTINCT FUNCTION_NAME from SAKAI_REALM_FUNCTION SRF inner ****
>
> >> join SAKAI_REA LM_RL_FN SRRF on SRF.FUNCTION_KEY = SRRF.FUNCTION_KEY **
> **
>
> >> inner join SAKAI_REALM_ROL E SRR on SRRF.ROLE_KEY = SRR.ROLE_KEY ****
>
> >> inner join SAKAI_REALM SR on SRRF.REALM_KE Y = SR.REALM_KEY where ****
>
> >> SRR.ROLE_NAME = :1 and SR.REALM_ID IN (:2 ,:3 ,:4 )****
>
> >> ****
>
> >> ****
>
> >> ## Patches previously run in production****
>
> >> KNL-1056        Need more efficient caching of notifyingMemoryStore
> object ****
>
> >> KNL-1016        Allow multiple site types for isCourseSite(),
> isProjectSite(), isPortfolioSite() ****
>
> >> ****
>
> >> ## Patches new to this build****
>
> >> KNL-989         Add tool groups****
>
> >> KNL-1060        Cache invalidation for grants isn't happening when
> editing a special realm****
>
> >> KNL-990         Joinable Groups****
>
> >> KNL-885         The group property to enable Site Info to see groups
> should be moved out of site-manage and into kernel-api****
>
> >> KNL-874         Replace getFormattedMessage array argument with a
> varargs ****
>
> >> ****
>
> >> _______________________________________________****
>
> >> 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"****
>
> ** **
>
> _______________________________________________****
>
> 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"****
>
> This message is private and confidential. If you have received it in
> error, please notify the sender and remove it from your system.
>
> _______________________________________________
> 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/20130805/e442561d/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 21485 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20130805/e442561d/attachment.png 