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

Matthew Jones matthew at longsight.com
Thu Aug 1 14:30:39 PDT 2013


Yea, if that is the ticket, you could put debug on
org.sakaiproject.authz.impl;

And see how often
"DbAuthzGroupService update(): clear realm role cache for <  >"

Is printed. Would also be worth checking the hit rate of that cache is.
Sounds like it would be really low verses your old version.

This is a cache from a sample instance.

*org.sakaiproject.authz.impl.DbAuthzGroupService.realmRoleGroupCache:
count:5822 hits:225439 misses:31470 hit%:87*


On Thu, Aug 1, 2013 at 5:19 PM, Aaron Zeckoski <azeckoski at unicon.net> wrote:

> Based on the jiras you listed, I would probably start here but that's
> just a guess:
> https://jira.sakaiproject.org/browse/KNL-1060
>
> -AZ
>
>
> On Thu, Aug 1, 2013 at 4:56 PM, 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"
>
>
>
> --
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
> _______________________________________________
> 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/20130801/91e3852c/attachment.html 


More information about the sakai-dev mailing list